快速发现Java应用响应变慢需先用jstack -l <pid>查WAITING/BLOCKED线程及重复锁对象，结合async-profiler录锁事件；GC干扰看GCDetails日志与jstat -gc；ConcurrentHashMap退化源于容量小、hashCode不均或computeIfAbsent耗时；线程池堆积要警惕CallerRunsPolicy和无界队列。
线程阻塞和锁竞争怎么快速发现
Java应用响应变慢、吞吐骤降，十有八九是线程卡在锁或IO上。别急着改代码，先看线程快照：jstack -l <pid> 输出里重点找 WAITING 和 BLOCKED 状态的线程堆栈，尤其是重复出现的锁对象（如 java.util.concurrent.locks.ReentrantLock$NonfairSync 或 synchronized 持有的 java.lang.Object 实例）。
常见误判点：
- 把
parking to wait for <0x...>当成死锁——其实只是正常 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 <pid>
GC 导致并发性能抖动怎么确认
并发线程频繁进入 SAFEPOINT、RT 波动大、CPU 利用率低但延迟高，大概率是 GC 干扰。开 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察日志中是否密集出现 Full GC 或单次 ParNew 耗时超 100ms。
关键线索：
立即学习“Java免费学习笔记（深入）”；
-
G1 Evacuation Pause中[Eden: ...->..., Survivor: ...->...]后面如果跟着大量to-space exhausted，说明 G1 回收不及，对象晋升太快，要检查是否有突发大对象或长生命周期缓存泄漏 - 用
jstat -gc <pid> 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 执行计划，而不是只盯着锁本身。
