Java并发编程中性能问题如何定位_排查思路总结

快速发现Java应用响应变慢需先用jstack -l 查WAITING/BLOCKED线程及重复锁对象，结合async-profiler录锁事件；GC干扰看GCDetails日志与jstat -gc；ConcurrentHashMap退化源于容量小、hashCode不均或computeIfAbsent耗时；线程池堆积要警惕CallerRunsPolicy和无界队列。

线程阻塞和锁竞争怎么快速发现

Java应用响应变慢、吞吐骤降，十有八九是线程卡在锁或IO上。别急着改代码，先看线程快照：jstack -l 输出里重点找 WAITING 和 BLOCKED 状态的线程堆栈，尤其是重复出现的锁对象（如 java.util.concurrent.locks.ReentrantLock$NonfairSync 或 synchronized 持有的 java.lang.Object 实例）。

常见误判点：

• 把 parking to wait for 当成死锁——其实只是正常 AQS 等待，得结合持有锁的线程是否在运行来判断
• 忽略 java.lang.Thread.State: TIMED_WAITING (on object monitor)，它可能正卡在 wait(timeout) 或 Object.wait()，背后往往是生产者-消费者模型的唤醒遗漏
• 用 jstack 抓瞬时快照容易漏掉短时阻塞，建议配合 async-profiler 录制 30 秒锁事件：

  ./profiler.sh -e lock -d 30 -f lock.html 

GC 导致并发性能抖动怎么确认

并发线程频繁进入 SAFEPOINT、RT 波动大、CPU 利用率低但延迟高，大概率是 GC 干扰。开 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察日志中是否密集出现 Full GC 或单次 ParNew 耗时超 100ms。

关键线索：

• G1 Evacuation Pause 中 [Eden: ...->..., Survivor: ...->...] 后面如果跟着大量 to-space exhausted，说明 G1 回收不及，对象晋升太快，要检查是否有突发大对象或长生命周期缓存泄漏
• 用 jstat -gc 1000 看 S0C/S1C（Survivor 容量）是否长期接近 0，这会导致对象直入老年代，加剧 CMS 或 G1 老年代压力
• 开启 -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log 可捕获 safepoint 停顿详情，定位是不是 GC 触发了全局停顿

ConcurrentHashMap put/get 性能异常慢的排查路径

不是所有

“并发安全”都等于“高性能”。ConcurrentHashMap 在以下场景会退化：

• 初始化容量过小（默认 16），且并发写入线程多 → 大量哈希冲突导致链表/红黑树深度增加 → 查找从 O(1) 退化为 O(log n)；应预估 size，显式构造：new ConcurrentHashMap(expectedSize / 0.75f + 1)
• key 的 hashCode() 实现不均（如永远返回固定值），所有 entry 都挤进同一个 bin → 锁粒度失效，实际串行化；用 Unsafe.compareAndSwapInt 自定义哈希时尤其要注意
• JDK 8+ 中 computeIfAbsent 若传入的 mappingFunction 执行耗时，会阻塞同一 bin 下其他操作；避免在 lambda 里做 DB 查询或远程调用
• 使用 size() 方法而非 isEmpty() —— 前者需遍历所有 segment 计数，后者只查一个 volatile 字段，差异可达毫秒级

线程池任务堆积却无拒绝日志？检查 CallerRunsPolicy 和队列类型

现象：监控显示 queue.size 持续上涨，但没看到 RejectedExecutionException，应用越来越慢。原因通常是用了 CallerRunsPolicy 或无界队列（如 LinkedBlockingQueue 默认 capacity=Integer.MAX_VALUE）。

真实影响：

• CallerRunsPolicy 会让提交线程自己执行任务，表面没异常，实则把业务线程拖进 CPU 密集型逻辑，造成线程饥饿；用 jstack 会发现大量业务线程堆栈停留在 ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
• 无界队列 + 固定大小 corePoolSize，等于把背压转移到内存——OOM 前只会越来越慢；应改用有界队列（如 ArrayBlockingQueue），并配合理想的 corePoolSize（通常 = CPU 核心数 × 1.5～2）
• 检查 allowCoreThreadTimeOut(true) 是否误开：它会让空闲 core 线程也回收，导致突发流量来临时重建线程开销大，反而降低吞吐

真正难的不是找到哪个线程在等，而是判断它该不该等、等多久才合理。比如一个 ReentrantLock.lockInterruptibly() 卡住 200ms，可能是数据库连接池耗尽，也可能是下游服务超时配置太松——得顺着堆栈里的 at com.xxx.dao.UserDao.selectById 往下查 SQL 执行计划，而不是只盯着锁本身。