Analyse the following Java GC log and provide a performance assessment and tuning recommendations.

GC log excerpt (paste 50-200 lines):
[PASTE GC LOG HERE]

Application context:
- Java version: [e.g. Java 21]
- GC algorithm: [e.g. G1GC / ZGC / Shenandoah / Parallel GC]
- Heap size: -Xms[N]g -Xmx[N]g
- Deployment: [e.g. Kubernetes pod, 4GB RAM limit]
- SLA: [e.g. p99 latency < 100ms, throughput > 500 req/s]

Extract and analyse these metrics from the log:
1. GC pause time: average, p95, p99, maximum — are any pauses violating the SLA?
2. GC frequency: how often is minor/major/full GC occurring?
3. Heap occupancy before and after each collection: is the heap growing? (leak indicator)
4. Promotion rate: how much data is being promoted from young to old generation per second?
5. Allocation rate: MB/s being allocated — is it sustainable for the heap size?
6. Full GC events: any stop-the-world full GC pauses? (should be rare/zero with G1/ZGC)

Based on the metrics, provide:
- Root cause of any SLA violations
- Specific JVM flag changes with justification:
  * G1GC: -XX:MaxGCPauseMillis, -XX:G1HeapRegionSize, -XX:G1NewSizePercent
  * ZGC: -XX:SoftMaxHeapSize, -XX:ZCollectionInterval
  * Common to all: -XX:+UseStringDeduplication, -XX:+AlwaysPreTouch
- Whether GC algorithm should be changed (e.g., switching from G1 to ZGC for <10ms latency)
- How to collect a more detailed GC log for deeper analysis

Analyse the following heap dump summary and identify memory leak suspects.

Heap dump top object counts (from Eclipse MAT "Dominator Tree" or jmap -histo output):
[PASTE THE TOP 30-50 LINES OF OBJECT HISTOGRAM OR DOMINATOR TREE HERE]

Application context:
- Java version: [e.g. Java 21]
- Framework: [e.g. Spring Boot 3.2]
- Heap size at time of dump: [e.g. 3.8GB used of 4GB max]
- Uptime before dump: [e.g. 18 hours]
- Expected baseline heap: [e.g. ~800MB under normal load]

Analysis to perform:

1. Identify object types that are unexpectedly large or numerous:
   - What objects dominate the retained heap?
   - Are there byte[], char[], or String objects out of proportion to the application's expected data volume?

2. Common leak patterns to check:
   - Static collections (static Map, static List) that grow without bound — classic "accidental singleton" leak
   - Event listeners or callbacks registered but never deregistered
   - ThreadLocal values not removed after request completion — leak = one entry per thread per lifetime
   - Hibernate/JPA first-level cache in a long-running transaction (session not closed)
   - HTTP connection pool connections not returned (ResponseBody not closed)
   - ClassLoader leaks (common in hot-reload environments; char[] arrays dominate)
   - Cache implementations with no eviction policy (unbounded ConcurrentHashMap used as a cache)

3. For each suspected leak:
   - Object type and estimated retained heap
   - Likely code location (which class/bean would own this object type?)
   - How to confirm: Eclipse MAT query or JFR event to verify
   - Fix: specific code change

4. Show the Eclipse MAT OQL query to find all instances of the suspected leaking class:
   SELECT * FROM [ClassName] WHERE [condition]

Evaluate whether the following Java service workload will benefit from virtual threads (Java 21+) and provide a migration plan.

Service class(es) to evaluate:
[PASTE YOUR SERVICE CLASSES HERE]

Current concurrency configuration:
[PASTE thread pool / executor configuration, e.g. server.tomcat.threads.max=200]

Workload profile:
- Typical request handling time: [e.g. 200ms]
- Breakdown of that time: [e.g. ~10ms CPU, ~150ms DB query, ~40ms external HTTP call]
- Concurrent users at peak: [e.g. 800]
- Current platform thread pool size: [e.g. 200 threads]

Evaluation criteria:

1. I/O-bound ratio: what percentage of request time is blocking I/O (DB, HTTP, file)?
   - If >70% I/O-bound: virtual threads will help significantly
   - If <30% I/O-bound (CPU-bound): virtual threads will NOT help — explain why

2. Carrier pinning risks in the codebase:
   - Any synchronized blocks wrapping blocking calls? (Prompt 2 of the Code Quality series)
   - Any use of native libraries via JNI that block while pinned?

3. Thread pool sizing recommendation:
   - Current: [N] platform threads
   - After virtual thread migration: Executors.newVirtualThreadPerTaskExecutor()
   - Expected throughput improvement at peak load

4. Migration steps:
   A. For Spring Boot 3.2+: spring.threads.virtual.enabled=true (one property, zero code changes)
   B. For older Spring Boot or non-Spring: replace thread pool executor with Executors.newVirtualThreadPerTaskExecutor()
   C. Replace Thread.sleep() with virtual-thread-friendly alternatives (none needed — sleep unmounts the virtual thread)
   D. Identify and rewrite synchronized + blocking patterns (CRITICAL step)

5. Benchmark design: show a JMH benchmark that measures this specific workload with platform vs virtual threads

See also: https://ankurm.com/virtual-threads-vs-platform-threads-benchmarks/

Analyse the following Java thread dump and identify contention bottlenecks.

Thread dump (from jstack, kill -3, or VisualVM):
[PASTE THE THREAD DUMP HERE — at minimum include all BLOCKED and WAITING threads]

Application context:
- Framework: [e.g. Spring Boot 3.x / Tomcat / Netty]
- Thread pool sizes: [e.g. Tomcat max-threads=200, HikariCP pool-size=20]
- Observed symptom: [e.g. "CPU near 0%, all requests timing out", "gradual slowdown over 30 minutes"]

Analysis steps:

1. Thread state summary:
   - How many threads are RUNNABLE / BLOCKED / WAITING / TIMED_WAITING?
   - A high ratio of BLOCKED threads indicates a lock contention bottleneck
   - All threads WAITING on HikariCP: pool exhaustion (too small or connection leak)

2. Lock contention analysis:
   - Identify the lock object that multiple BLOCKED threads are waiting for
   - Identify the thread that HOLDS the lock — what is it doing?
   - Is the lock holder also waiting for something? (deadlock indicator)

3. Deadlock detection:
   - List any cycles in the "waiting for / held by" chain
   - Show the exact threads and locks involved in the deadlock
   - Propose the fix (consistent lock ordering, or eliminating nested locking)

4. Common contention patterns to identify:
   - HikariCP pool exhaustion: all threads waiting at HikariDataSource.getConnection()
     Fix: increase pool size or find the connection leak
   - Tomcat thread pool exhaustion: all threads blocked at downstream HTTP calls
     Fix: migrate to virtual threads or async/non-blocking I/O
   - Log4j/Logback AsyncAppender queue full: all threads blocked at log.info()
     Fix: increase queue size or use synchronous appender for critical logs
   - JVM class loading lock: threads waiting at ClassLoader.loadClass()
     Fix: warm up the application before routing production traffic

5. Recommended actions ranked by impact

Calculate and configure the optimal HikariCP connection pool for the following deployment.

Current HikariCP configuration:
[PASTE spring.datasource.hikari.* properties]

Deployment parameters:
- Database: [e.g. PostgreSQL 16 on AWS RDS db.r6g.large]
- Database max_connections: [e.g. 200 — from SHOW max_connections; in psql]
- Number of application pods/instances: [e.g. 4 pods]
- Pod CPU: [e.g. 2 vCPU]
- Application thread pool size: [e.g. 200 Tomcat threads per pod, or virtual threads]
- Typical query duration: [e.g. p50=5ms, p99=80ms]

Pool sizing formula to apply:
For CPU-bound workloads: pool_size = (core_count * 2) + effective_spindle_count
For I/O-bound workloads (typical REST API): pool_size = concurrent_transactions * average_query_duration_seconds / desired_throughput_per_connection

Safety rule: total connections across ALL pods MUST be < max_connections - 5 (leave headroom for admin connections and monitoring tools)

Calculate and set:
1. maximumPoolSize: [calculated value with justification]
2. minimumIdle: [usually = maximumPoolSize for stable connection count]
3. connectionTimeout: 30000ms (fail fast rather than queue indefinitely — prevents cascade failure)
4. idleTimeout: 600000ms (10 minutes — close idle connections before the DB kills them)
5. maxLifetime: 1800000ms (30 minutes — rotate connections before the DB's wait_timeout)
6. keepaliveTime: 60000ms (send keepalive query to prevent firewall/LB from killing idle connections)
7. connectionTestQuery (only if JDBC4 validation is not supported): SELECT 1

Also generate:
- The Actuator endpoint configuration to expose HikariCP metrics: management.metrics.enable.hikaricp=true
- A Grafana/Prometheus query to alert when active connections > 80% of pool size
- How to diagnose a connection leak using HikariCP's leak detection threshold:
  spring.datasource.hikari.leak-detection-threshold=5000

Analyse and optimise the following Java Stream pipelines for performance.

Method(s) to optimise:
[PASTE THE METHODS CONTAINING STREAM PIPELINES HERE]

Context:
- Approximate collection sizes at runtime: [e.g. "orders list: 10,000–50,000 elements"]
- Call frequency: [e.g. "called 200 times/second"]
- Current latency: [e.g. "p99 = 450ms, target = <50ms"]

Performance issues to check and fix:

1. Terminal operation ordering — filter before map:
   stream.map(expensiveTransform).filter(predicate) — transforms ALL elements, then filters
   Fix: stream.filter(predicate).map(expensiveTransform) — filters first, only transforms survivors

2. Unnecessary boxing/unboxing:
   List<Integer> ids stream .mapToInt(Integer::intValue).sum() — boxing each int
   Fix: Use primitive streams: IntStream, LongStream, DoubleStream to avoid heap allocation for primitives

3. Collecting to a list and then streaming again:
   list.stream().filter(...).collect(Collectors.toList()).stream().map(...) — creates intermediate list
   Fix: chain the operations into a single pipeline

4. Using sorted() on a large stream without needing full sort order:
   If you only need the top N results: use sorted().limit(N) which is only O(N log N) not O(M log M)
   Better: use a PriorityQueue for top-N to avoid sorting the entire stream

5. Parallel streams on small collections or I/O-bound work:
   Small collections (<10,000 elements): parallel stream overhead exceeds the benefit
   I/O-bound operations (DB calls, HTTP): parallel streams block ForkJoinPool threads — use virtual threads instead
   Fix: add a size threshold check before enabling parallel

6. Grouping into a Map where only count or sum is needed:
   .collect(Collectors.groupingBy(key)) then map.get(k).size() — loads all objects into groups
   Fix: .collect(Collectors.groupingBy(key, Collectors.counting()))

For each optimisation: show the before stream, the after stream, and the estimated improvement (Big-O or allocation reduction).

Review and improve the following JVM flags for a production Spring Boot deployment.

Current JVM flags:
[PASTE YOUR JAVA_OPTS OR JVM_ARGS HERE, e.g.
-Xms2g -Xmx2g -XX:+UseG1GC -verbose:gc]

Deployment context:
- Java version: [e.g. 21]
- Container: [e.g. Kubernetes pod with 4GB memory limit, 2 CPU limit]
- Application type: [e.g. REST API, 500 req/s peak]
- Latency SLA: [e.g. p99 < 100ms]

Review each flag and add the following if missing:

CONTAINER AWARENESS (critical for Kubernetes):
- -XX:+UseContainerSupport (enabled by default Java 8u191+, 11+ — verify it is not disabled)
- -XX:MaxRAMPercentage=75.0 — use 75% of container memory limit as heap max (better than hardcoded -Xmx in containers)
- -XX:InitialRAMPercentage=50.0 — start at 50% to allow heap growth without immediate OOM
- Remove hardcoded -Xmx if -XX:MaxRAMPercentage is set (they conflict)

GC CONFIGURATION:
- For latency-sensitive (<10ms pauses): recommend ZGC: -XX:+UseZGC -XX:SoftMaxHeapSize=3g
- For throughput-oriented: G1GC with -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=16m
- -XX:+AlwaysPreTouch — pre-fault all heap pages at startup (eliminates GC pauses from page faults under load)

STARTUP PERFORMANCE:
- -XX:TieredStopAtLevel=1 (development/short-lived only — disables C2 JIT, not suitable for production)
- -XX:+UseStringDeduplication (G1GC only — deduplicates String objects in old gen)

DIAGNOSTIC AIDS (low overhead in production):
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof
- -XX:+ExitOnOutOfMemoryError — crash fast on OOM instead of limping along
- -Xlog:gc*:file=/var/log/gc.log:time,uptime:filecount=5,filesize=20m — rolling GC log

Flag deprecation check: identify any flags that were removed or renamed in the target Java version.

Write a JMH microbenchmark comparing the following two Java implementations.

Implementation A (current):
[PASTE IMPLEMENTATION A HERE]

Implementation B (proposed optimisation):
[PASTE IMPLEMENTATION B HERE]

What is being measured: [e.g. "JSON serialisation of an Order object", "filtering a list of 10,000 products", "UUID generation strategy"]

Generate a complete JMH benchmark class with:

1. @BenchmarkMode({Mode.Throughput, Mode.AverageTime}) — measure both throughput and latency
2. @OutputTimeUnit(TimeUnit.MICROSECONDS)
3. @Warmup(iterations = 5, time = 1) — 5 warmup iterations to reach JIT steady state
4. @Measurement(iterations = 10, time = 1) — 10 measurement iterations
5. @Fork(2) — run in 2 separate JVM forks to reduce JVM startup variance
6. @State(Scope.Benchmark) — shared state (the input data) initialised once per fork
7. @Setup(Level.Trial) — initialise test data in @Setup, not in the benchmark method itself

Common pitfalls to avoid (show how you avoided each):
- Dead code elimination: consume the result with Blackhole.consume(result) or return it from the benchmark method
- Constant folding: the input data must not be compile-time constants — use @Param or instance fields
- Loop overhead: avoid explicit loops inside the benchmark method — JMH handles iteration

Also generate:
- The Maven pom.xml addition for jmh-core and jmh-generator-annprocess
- The command to run the benchmark: java -jar benchmarks.jar -rff results.json
- How to interpret the results: what does ops/ms mean, when is a difference statistically significant
- A note on when NOT to use JMH (integration-level performance testing belongs in Gatling/k6, not JMH)

Analyse and optimise the following Java hot method identified by a profiler.

Hot method (the full class, not just the method):
[PASTE THE CLASS CONTAINING THE HOT METHOD HERE]

Profiler output:
[PASTE THE PROFILER FLAME GRAPH TOP METHODS OR JFR SUMMARY — e.g.:
  45.2% com.example.OrderService.calculateTotals(...)
  12.1% java.util.HashMap.get(...)
  8.3%  java.lang.String.format(...)
  ...]

Method call frequency: [e.g. "called 50,000 times per second"]
Input characteristics: [e.g. "input list contains 200–500 OrderItem objects on average"]

Performance analysis to perform:

1. Algorithmic complexity:
   - Is the method O(n²) when O(n) is achievable? (nested loops, contains() on a List instead of a Set)
   - Is a sorting operation O(n log n) when the result only needs top-N items?

2. Allocation hotspots:
   - Are temporary objects created inside a tight loop that GC must reclaim on every call?
   - String concatenation in a loop: use StringBuilder (or formatted() for simple cases)
   - New ArrayList/HashMap created per call when a pre-allocated reusable structure would serve

3. Repeated computation:
   - Is the same derived value computed multiple times within one invocation?
   Fix: compute once, store in a local variable

4. Expensive lookups in a loop:
   - map.get(key) inside a loop where key repeats → cache the value outside the loop
   - service.findById(id) inside a loop → batch-load all IDs before the loop

5. Reflection or String.format in hot path:
   - MessageFormat.format() or String.format() is 5-10x slower than concatenation for simple cases
   Fix: use string templates (Java 21+) or pre-compiled MessageFormat for repeated patterns

For each finding: before code, after code, and estimated improvement (allocation rate reduction or CPU percentage point).

Perform a production performance readiness review for the following Spring Boot application.

Provide the following artefacts for analysis:

1. JVM flags (JAVA_OPTS):
[PASTE JVM FLAGS]

2. application.yml (full file):
[PASTE application.yml]

3. Key service classes (the 2-3 classes in the critical request path):
[PASTE SERVICE CLASSES]

4. Repository interfaces and any custom @Query methods:
[PASTE REPOSITORIES]

5. Entity classes:
[PASTE ENTITIES]

Application profile:
- Peak load: [e.g. 1,000 req/s]
- Latency target: [e.g. p99 < 150ms]
- Deployment: [e.g. 3 Kubernetes pods, 2 CPU / 4GB each, PostgreSQL RDS r6g.large]
- Java version: [e.g. 21]

Review dimensions:

JVM LAYER:
[ ] Container-aware heap sizing (MaxRAMPercentage vs hardcoded Xmx)
[ ] GC algorithm appropriate for latency target
[ ] Diagnostic flags present (HeapDumpOnOutOfMemoryError, GC logging)
[ ] ExitOnOutOfMemoryError configured

DATA ACCESS LAYER:
[ ] HikariCP pool size calculated correctly for DB max_connections / pod count
[ ] open-in-view disabled
[ ] N+1 query patterns in service layer
[ ] Bulk operations using JDBC batching
[ ] @Cacheable on read-heavy, infrequently-changing data

APPLICATION LAYER:
[ ] Synchronised blocks wrapping blocking I/O (carrier pinning)
[ ] Thread pool sized for workload (or virtual threads enabled)
[ ] Large object allocations in hot paths
[ ] Unbounded in-memory collections (cache without eviction)
[ ] External HTTP calls without timeout configuration

For each finding: severity (CRITICAL/HIGH/MEDIUM/LOW), component, description, fix, and estimated improvement.