Java并发编程常见误区解析

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《Java并发编程常见错误与误区解析》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

volatile不能保证原子性，因count++含读-改-写三步且可被穿插；ThreadLocal易致内存泄漏，因key弱引用而value强引用未remove；submit(Runnable)会吞异常，需get()或UncaughtExceptionHandler捕获；ConcurrentHashMap的size()非实时精确值。

volatile 不能保证原子性，别把它当锁用

很多人看到 volatile 能禁止指令重排、保证可见性，就以为它能替代 synchronized 或 AtomicInteger。结果写了个 volatile int count = 0，再在多线程里反复执行 count++，最后发现结果远小于预期。

根本原因是： count++ 是三步操作（读取、加1、写回），volatile 只保证每一步的读写可见，不保证这三步不被其他线程穿插执行。

• 正确做法：对计数类操作，优先用 AtomicInteger；需要复合逻辑时，必须用 synchronized 或 ReentrantLock
• 适用场景：volatile 适合纯状态标记，比如 volatile boolean running = true 配合 while 循环做停止控制
• 常见错误现象：程序偶发逻辑跳过、状态未及时更新、while(true) 死循环停不下来

ThreadLocal 不是线程安全的“银弹”，内存泄漏很真实

ThreadLocal 看似让每个线程独占变量，但它的值实际存放在当前线程的 Thread.threadLocals（一个 ThreadLocalMap）里。而这个 map 的 key 是弱引用，value 是强引用 —— 如果没手动调用 remove()，在线程复用（如线程池）场景下，value 就可能一直卡在 map 里出不去。

典型表现：堆内存持续上涨，dump 后发现大量 ThreadLocalMap$Entry 持有业务对象，且 key 为 null。

• 必须配对使用：set() 后，在业务逻辑结束前调用 remove()，尤其在 try-finally 中保障执行
• 别在 ThreadLocal 里存大对象或上下文全量数据，容易放大泄漏影响
• Spring 的 RequestContextHolder、MyBatis 的 SqlSession 管理都依赖 ThreadLocal，但它们内部都做了 clean 清理

ExecutorService.submit() 抛异常不会直接崩主线程，但很容易被忽略

用 executor.submit(Runnable) 提交任务后，如果任务内部抛了未捕获异常，它不会打印堆栈，也不会中断主线程，而是悄悄吞掉 —— 异常被封装进 Future，只有你显式调用 get() 才会重新抛出。

这就导致很多线上问题：任务失败了，日志没报错，监控没告警，但下游数据就是不对。

• 推荐写法：统一用 submit(Callable)，并在 finally 块中调用 future.get(1, TimeUnit.SECONDS) 做兜底检查（注意超时避免阻塞）
• 更稳妥的方式：自定义 ThreadFactory 给线程设置 UncaughtExceptionHandler，或者用 afterExecute 钩子捕获异常
• 别依赖 IDE 自动补全的 submit(Runnable)，它对错误最不友好

ConcurrentHashMap 的 size() 和 isEmpty() 不是实时强一致的

很多人以为 ConcurrentHashMap 既然是“并发安全”的 Map，那 size() 就该返回精确值。实际上，它内部是分段统计再汇总，过程中可能有 put/remove 正在进行，所以返回的是一个**估算值** —— 文档明确写了 “may be somewhat inaccurate”。

同理，isEmpty() 也只是检查所有 segment 是否都为空，无法 100% 保证下一毫秒不被插入。

• 不要用 map.size() == 0 替代 map.isEmpty()，两者语义和性能都不等价
• 千万别拿 size() 做循环条件或阈值判断（比如“等元素满100个再批量处理”），这会导致行为不可预测
• 真要精确计数，得配合 LongAdder 或外部原子变量维护，而不是查 Map 自身

并发问题的麻烦之处不在于写不出来，而在于“看起来跑通了”。很多错误只在高并发、长周期、JVM 参数变动或 GC 后才暴露，所以别轻信本地测试结果，更别把“没报错”当成“正确”。

今天关于《Java并发编程常见误区解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！