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。
立即学习“Java免费学习笔记（深入）”；
- 必须配对使用：
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 后才暴露，所以别轻信本地测试结果，更别把“没报错”当成“正确”。
