原文来自于：zha-ge.cn/java/68
Java 线程安全详解：定义、常见问题与解决方案
大家好，我又双叒叕来写流水账了。这次说点"老生常谈"的：线程安全。要不是上周现场出Bug让小组猝不及防，我还真不会想把多年踩坑心路写下来。闲话不多说，往下看吧，绝对比《Java 并发编程实战》好消化，起码气氛活跃！
线程安全？等会，这玩意不就是锁吗
有时候刚入行的小伙伴听到"线程安全"三个字，总觉得神神秘秘。其实本质不复杂。来个极简版解释：
- 线程安全就是并发多线程访问同一资源，不出错/出脏数据。
- 不安全就像：两个人同时写你日记，最后内容全糊了。
- 线程安全就像：有人守在门口，只准一个人写日记，其他人排队。
天天喊线程安全，实战中最常见"事故"就是数据竞争。比如全局计数器、单例模式、共享集合......全是高发地带。
日常开发，看似平静水面下的"风暴"
先说说我去年翻车的小故事。我们有个在线打卡统计，后台用一个静态Map<LocalDate, Integer>记录每一天的打卡人数：
java
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。 - 操作时「不变式」也要守，比如不在多个步骤拆开操作。
比如把上面的计数器改成这样：
java
private static final ConcurrentMap<LocalDate, AtomicInteger> attendanceMap = new ConcurrentHashMap<>();
attendanceMap.computeIfAbsent(date, d -> new AtomicInteger(0)).incrementAndGet();一行解决竞争，后面就很少再出诡异数字了。
经验启示
写半天，发现老道理还是那套：
- 宁滥勿缺：不确定是否线程安全，先查文档 or 用并发类/锁，甭心疼几行代码。
- 可变状态最危险：别随便让对象在多线程下可写，哪怕"只加一行"都容易炸。
- 集合类优先并发版：99%的坑都能规避，别贪那几微秒性能。
- 多线程下，所有假设都要怀疑：面试吹牛说"线程安全"，实战就埋着坑------光修Bug都忙不过来。
最后，送大家一句程序员朋友圈名言：
"真正的并发Bug不会在本地出现，也不是今天立马炸，是六个月后，半夜，老板睡觉前......"
收个尾，线程安全问题其实随处见，别觉得老生常谈，真玩多线程的时候，坑永远比你想象的深。祝大家多写代码少掉头发，实在踩坑主动总结，比什么教程都顶用。
完！