Java并发编程30个高频考点解析

Java并发编程远不止掌握Thread和synchronized那么简单，30个高频考点直指线上故障核心——从volatile无法保障i++原子性、ConcurrentHashMap JDK8后摒弃分段锁改用细粒度synchronized、线程池拒绝策略本质无法彻底防丢任务，到CompletableFuture链式调用中thenApply与thenAccept的关键语义差异，每个细节都暗藏“看不见的竞争条件”：ThreadLocal泄漏、SimpleDateFormat非线程安全、Future.get()无超时导致雪崩……这些看似微小的误用，恰恰是12个以上典型生产事故的直接推手，读懂它们，才是跨越并发雷区、写出真正高可用代码的第一步。

Java并发编程不是“会用Thread和synchronized”就过关了——30个高频考点里，至少有12个是线上故障的直接诱因，比如ConcurrentModificationException在遍历时改集合、volatile误当原子操作用、ExecutorService不shutdown()导致线程泄漏。

为什么volatile不能保证i++的线程安全

它只解决可见性和禁止重排序，不解决“读-改-写”的原子性。JVM执行i++实际拆成三步：读i值 → 加1 → 写回，两个线程可能同时读到旧值，各自+1再写，结果只加了一次。

• 适用场景：boolean running = true这类纯状态标记，且写操作不依赖当前值
• 错误用法：volatile int count = 0;然后多线程做count++
• 替代方案：用AtomicInteger.incrementAndGet()，或锁住整个操作

ConcurrentHashMap在JDK 8之后还锁分段吗

不锁了。JDK 8彻底废弃Segment，改用synchronized锁单个Node（链表头或红黑树根），锁粒度更细；扩容时支持多线程协助迁移，吞吐提升明显。

• 注意点：size()不是O(1)，它要遍历所有CounterCell累加，高并发下可能不准
• 别在遍历中调remove()或put()——虽然不会抛ConcurrentModificationException，但可能漏掉刚插入的元素
• JDK 7的size()靠多次尝试+重试，JDK 8改用sumCount()，逻辑更清晰但仍有微小误差

ThreadPoolExecutor拒绝策略选哪个才不丢任务

没有“不丢任务”的银弹。四种内置策略本质是不同取舍：AbortPolicy抛异常（最常用）、CallerRunsPolicy让调用线程自己执行（可减缓提交速度）、DiscardPolicy静默丢弃、DiscardOldestPolicy丢队列头任务。

• 生产环境慎用CallerRunsPolicy：如果调用线程是Web容器线程（如Tomcat的http-nio-8080-exec-5），会让请求响应变慢甚至超时
• 自定义拒绝策略要小心：打印日志可能引发Logger锁竞争，建议异步落库或发告警
• 真正防丢任务得靠上游限流（如Sentinel）+ 持久化队列（如Kafka），线程池只是最后一道缓冲

CompletableFuture的thenApply和thenAccept到底差在哪

前者接收前序结果并返回新值，能链式传递；后者只消费结果，返回CompletableFuture，链中断。错用会导致编译失败或NPE。

• thenApply：适合转换，比如future.thenApply(s -> s.length())，返回CompletableFuture
• thenAccept：适合副作用，比如future.thenAccept(System.out::println)，后续不能再thenApply
• 容易踩坑：用thenAccept后接join()没问题，但若想再处理返回值，必须从thenApply开始重写链

并发问题最难的不是语法，是“看不见的竞争条件”——比如ThreadLocal在线程池里不清理、SimpleDateFormat被多个线程共用、Future.get()没设超时卡死整个调用链。这些细节不写进日志，就只能靠复现和猜。

终于介绍完啦！小伙伴们，这篇关于《Java并发编程30个高频考点解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！