原文来自于：https://zha-ge.cn/java/68

Java 线程安全详解：定义、常见问题与解决方案

大家好，我又双叒叕来写流水账了。这次说点“老生常谈”的：线程安全。要不是上周现场出Bug让小组猝不及防，我还真不会想把多年踩坑心路写下来。闲话不多说，往下看吧，绝对比《Java 并发编程实战》好消化，起码气氛活跃！

线程安全？等会，这玩意不就是锁吗

有时候刚入行的小伙伴听到“线程安全”三个字，总觉得神神秘秘。其实本质不复杂。来个极简版解释：

• 线程安全就是并发多线程访问同一资源，不出错/出脏数据。
• 不安全就像：两个人同时写你日记，最后内容全糊了。
• 线程安全就像：有人守在门口，只准一个人写日记，其他人排队。

天天喊线程安全，实战中最常见“事故”就是数据竞争。比如全局计数器、单例模式、共享集合……全是高发地带。

日常开发，看似平静水面下的“风暴”

先说说我去年翻车的小故事。我们有个在线打卡统计，后台用一个静态Map<LocalDate, Integer>记录每一天的打卡人数：

private static final Map<LocalDate, Integer> attendanceMap = new HashMap<>();
// 业务代码每次递增
attendanceMap.put(date, attendanceMap.getOrDefault(date, 0) + 1);

图省事直接用HashMap，结果某个早高峰打卡人数突然“倒退”，甚至-1……经理还以为库被攻破，搞得人心惶惶。

其实，这种“奇怪数字”80%都跟线程安全有关，不信你加点并发压力测测，轻松复现。

踩坑瞬间

一般人踩线程安全的坑，都可以开个系列：

• 用普通集合(List、Map)存并发数据。
• 手写单例模式，结果多线程下new出好几个。
• 以为synchronized就是万能银弹，却没锁住“该锁的地方”。
• 不小心把可变数据暴露出去，被别的线程偷偷改了。

说出来都是泪。举个我的现场“名场面”吧：

有次想偷懒，没用并发集合。觉得反正一次只加一，顶多慢点。
结果：

• 早上打卡9:00，上报人数：56，上升的数字很欢快，偶尔会跳成53。
• 细查日志，两个线程几乎同时读出老值，然后都+1再覆写——等于有一票白打。

最当场出糗是历史数据莫名倒退，用户一脸懵：“我明明刷了脸，怎么又少一个？”

三板斧破局：让线程安全落地

后来当然开始猛补线程安全姿势。总结下来，其实可用的套路就几个：

• 换用“并发安全类”：ConcurrentHashMap、CopyOnWriteArrayList等。
• 关键路径加synchronized，不嫌慢的就全锁住。
• 原子操作搞定数值型，比如 AtomicInteger。
• 操作时「不变式」也要守，比如不在多个步骤拆开操作。

比如把上面的计数器改成这样：

private static final ConcurrentMap<LocalDate, AtomicInteger> attendanceMap = new ConcurrentHashMap<>();
attendanceMap.computeIfAbsent(date, d -> new AtomicInteger(0)).incrementAndGet();

一行解决竞争，后面就很少再出诡异数字了。

经验启示

写半天，发现老道理还是那套：

• 宁滥勿缺：不确定是否线程安全，先查文档 or 用并发类/锁，甭心疼几行代码。
• 可变状态最危险：别随便让对象在多线程下可写，哪怕“只加一行”都容易炸。
• 集合类优先并发版：99%的坑都能规避，别贪那几微秒性能。
• 多线程下，所有假设都要怀疑：面试吹牛说“线程安全”，实战就埋着坑——光修Bug都忙不过来。

最后，送大家一句程序员朋友圈名言：

“真正的并发Bug不会在本地出现，也不是今天立马炸，是六个月后，半夜，老板睡觉前……”

收个尾，线程安全问题其实随处见，别觉得老生常谈，真玩多线程的时候，坑永远比你想象的深。祝大家多写代码少掉头发，实在踩坑主动总结，比什么教程都顶用。

完！