Java并发编程中的并发执行与性能分析_技术教程

ExecutorService 提交大量任务后响应变慢，主因是任务排队、上下文切换和锁竞争；常见表现为 Future.get() 长时间阻塞或 completedTaskCount 增长缓慢，需检查无界队列、同步日志、拒绝策略，并用 jstack/VisualVM 定位锁争用点，避免 ForkJoinPool.commonPool() 用于 IO 场景。

为什么 `ExecutorService` 提交大量任务后响应变慢？

不是线程池不够大，而是任务排队、上下文切换和锁竞争在悄悄拖垮性能。常见表现是 submit() 调用不卡，但 Future.get() 长时间阻塞，或 ThreadPoolExecutor.getCompletedTaskCount() 增长极慢。

检查是否用了 LinkedBlockingQueue 且未设容量上限——默认无界队列会吃光堆内存，GC 频繁拖慢整体节奏
避免在任务中调用 System.out.println() 或同步日志——PrintStream 内部是 synchronized 方法，高并发下成热点锁
确认拒绝策略：用 AbortPolicy 能快速暴露过载，而 CallerRunsPolicy 表面“不丢任务”，实则把压力转嫁回主线程，掩盖真实瓶颈

如何用 `jstack` 和 `VisualVM` 定位线程阻塞点？

别等服务超时再查，要在压测中实时抓取。重点不是看“有多少线程”，而是看“哪些线程在等什么”。

jstack -l 输出里搜 java.lang.Thread.State: BLOCKED，接着看 waiting to lock 对应的锁地址，再往上翻找哪个线程正持有它
在 VisualVM 的 “Threads” 标签页，开启“Monitor CPU”后点击 “Thread Dump”，对比两次 dump 中长期处于 WAITING (on object monitor) 的线程栈
特别注意 ReentrantLock.lock()、ConcurrentHashMap.computeIfAbsent()（某些 JDK 版本在 hash 冲突严重时会锁住整个 bin）、CopyOnWriteArrayList.add() 这些看似线程安全、实则隐含锁粒度陷阱的操作

`ForkJoinPool.commonPool()` 为什么在 IO 密集场景下反而更慢？

它的设计目标是 CPU 密集型递归任务（如分治排序、并行流处理数组），工作窃取机制对随机延迟的 IO 操作完全无效，还增加调度开销。

遇到数据库查询、HTTP 调用、文件读写，必须显式创建独立的 ExecutorService，比如 Executors.newFixedThreadPool(10)，并控制最大并发数匹配下游承载力
CompletableFuture.supplyAsync(() -> {...}, executor) 必须传入自定义 executor，否则默认走 commonPool()，哪怕你写了 thenApplyAsync 也逃不掉
JDK 19+ 引入了 StructuredTaskScope，更适合 IO 并发编排，但需配合虚拟线程（Thread.ofVirtual()）使用，普通平台线程仍不适用

// 错误：全部跑在 commonPool，IO 任务卡住整个池
CompletableFuture.supplyAsync(() -> httpClient.get("/api/user"))
                 .thenApplyAsync(data -> parseJson(data));

// 正确：IO 专用线程池，CPU 密集操作才进 commonPool
ExecutorService ioPool = Executors.newFixedThreadPool(8);
CompletableFuture.supplyAsync(() -> httpClient.get("/api/user"), ioPool)
                 .thenApplyAsync(data -> parseJson(data)); // 这里没指定 executor，parseJson 是 CPU 密集，可放心用 commonPool

真正卡住并发性能的，往往不是线程数配得少，而是没意识到某个 ConcurrentHashMap 的 key 设计导致所有写操作挤在同一个 segment 上，或者一个本该异步的日志回调被错误地塞进了同步执行链路。这些细节不会报错，只会让吞吐量在 200 QPS 和 2000 QPS 之间反复横跳。