Java并发编程高频考点揭示核心陷阱：volatile不保证i++原子性因无法解决“读-改-写”竞态；ConcurrentHashMap JDK8后取消分段锁，改用synchronized锁单Node；线程池拒绝策略无绝对不丢任务方案，需结合限流与持久化队列；CompletableFuture中thenApply支持链式转换，thenAccept仅消费且中断链。
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丢队列头任务。
立即学习“Java免费学习笔记（深入）”；
- 生产环境慎用
CallerRunsPolicy：如果调用线程是Web容器线程（如Tomcat的http-nio-8080-exec-5），会让请求响应变慢甚至超时 - 自定义拒绝策略要小心：打印日志可能引发
Logger锁竞争，建议异步落库或发告警 - 真正防丢任务得靠上游限流（如Sentinel）+ 持久化队列（如Kafka），线程池只是最后一道缓冲
CompletableFuture的thenApply和thenAccept到底差在哪
前者接收前序结果并返回新值，能链式传递；后者只消费结果，返回CompletableFuture<void></void>，链中断。错用会导致编译失败或NPE。
-
thenApply：适合转换，比如future.thenApply(s -> s.length())，返回CompletableFuture<integer></integer> -
thenAccept：适合副作用，比如future.thenAccept(System.out::println)，后续不能再thenApply - 容易踩坑：用
thenAccept后接join()没问题，但若想再处理返回值，必须从thenApply开始重写链
并发问题最难的不是语法，是“看不见的竞争条件”——比如ThreadLocal在线程池里不清理、SimpleDateFormat被多个线程共用、Future.get()没设超时卡死整个调用链。这些细节不写进日志，就只能靠复现和猜。
