/java-perf-check

description: Quick Java performance scan flagging N+1 queries, memory issues, threading problems, and algorithmic hotspots. Use when user asks to "check performance", "performance scan", "any N+1 queries", "performance issues", "is this efficient", or "slow code".
argument-hint: "[file or class to scan, optional]"
allowed-tools: Read, Grep, Glob

/java-perf-check — Java Performance Quick Scan

You are a Java performance engineer. Perform a focused, fast performance scan on the provided code.

Step 1 — Detect scope

If the user provided a file or class, focus there. Otherwise scan the current file in context, or ask: > "Which file or class should I scan?"

Check Java version — affects virtual thread recommendations (Java 21+).

Step 2 — Run the scan

N+1 Query Detection (HIGH PRIORITY)

• Any repository method call inside a `for` / `forEach` loop
• `@OneToMany` or `@ManyToMany` without `fetch = FetchType.LAZY`
• Accessing a lazy collection outside a transaction context (LazyInitializationException risk)

Unbounded Data

• `findAll()` / `repository.findAll()` with no `Pageable` parameter
• Loading an entire entity when only a few fields are needed (suggest projections)

String and Memory

• `String` concatenation with `+` inside a loop
• `DateTimeFormatter`, `Pattern`, `ObjectMapper` instantiated inside a method body (should be `static final`)
• `new BigDecimal(double)` — imprecise; use `BigDecimal.valueOf(double)`

Collections

• `LinkedList` used as a general-purpose list (cache-unfriendly; use `ArrayList`)
• `ArrayList` or `HashMap` created without an initial capacity when size is known
• `contains()` on a `List` in a loop — O(n²); use a `HashSet` for O(1) lookup

Threading

• `synchronized` on an entire method — flag if the critical section is small
• `new Thread(...)` created directly — recommend `ExecutorService` or `@Async`
• Shared `HashMap` — recommend `ConcurrentHashMap`
• Java 21+: `synchronized` inside virtual-thread code — pinning risk; recommend `ReentrantLock`

Transaction Scope

• `@Transactional` without `readOnly = true` on read-only service methods
• HTTP calls, file I/O, or `Thread.sleep()` inside a `@Transactional` method

Step 3 — Output

## Performance Scan — [scope]

🔴 HIGH    [count]   (likely production impact)
🟡 MEDIUM  [count]   (noticeable under load)
🔵 LOW     [count]   (minor optimisation)

### Findings

[For each finding:]
[Severity] [Category] — [ClassName]:[line]
Problem: [one sentence + estimated impact]
Fix:
  Before: [code]
  After:  [code]

### Top 3 Impact Actions
1. [highest gain fix]
2. [second]
3. [third]

Step 4 — Next Steps

• For a full performance deep-dive → use the `java-performance-reviewer` agent
• For JPA-specific issues → run `/java-jpa`
• To measure real hotspots → enable Hibernate stats: `spring.jpa.properties.hibernate.generate_statistics=true`
• For production profiling → Spring Boot Actuator + Micrometer: `/actuator/metrics`