线程安全需在理解共享、时序与可见性基础上做设计取舍，核心是让多线程访问共享状态时行为可预测、结果可验证、性能不崩坏；优先减少共享（局部变量、ThreadLocal、消息传递），按场景选同步机制（原子类、读写锁、无锁容器），严守锁顺序与持有时间，并通过静态检查、动态监控和压力测试验证正确性。
线程并发安全不是靠“加锁就完事”，而是在理解共享、时序与可见性基础上，做有意识的设计取舍。核心目标是：让多线程访问共享状态时，行为可预测、结果可验证、性能不崩坏。
明确哪些数据必须共享，哪些可以隔离
共享是并发问题的源头，但并非所有数据都需要跨线程共享。优先从设计上减少共享：
- 用局部变量替代全局或静态变量，尤其在循环或递归逻辑中
- 对每个线程独占的数据，使用
ThreadLocal（Java）或thread_local（C++）隔离上下文，比如用户会话、事务ID、临时缓存 - 在微服务或模块化架构中，将状态封装在有界上下文内，通过消息传递代替直接内存共享
选对同步机制，而不是只选“最熟的那个”
不同场景适用不同工具，强行统一用 synchronized 或 mutex 往往埋下性能或死锁隐患：
- 简单计数器、开关标志 → 用
AtomicInteger（Java）、std::atomic<int>（C++）或sync/atomic（Go），避免锁开销 - 临界区逻辑较重、需条件等待 → 用可重入锁（
ReentrantLock/std::recursive_mutex），配合ConditionVariable或await/signal - 高频读+低频写 → 考虑读写锁（
ReentrantReadWriteLock/std::shared_mutex），但注意写饥饿风险 - 集合操作频繁 → 直接选用线程安全类型，如
ConcurrentHashMap、CopyOnWriteArrayList或sync.Map，而非在外层加锁包装普通容器
多锁场景必须遵守固定顺序，且控制持有时间
两个及以上锁同时出现时，顺序混乱是死锁温床，长时间持有则是性能瓶颈：
- 为所有锁定义全局唯一编号（如按资源名哈希或枚举排序），所有线程严格按升序申请
- 用
std::lock（C++）或Lock.tryLock(timeout)（Java）替代嵌套lock.lock()，避免阻塞式等待 - 临界区只放真正需要保护的代码——计算、赋值、状态变更；日志、网络调用、对象构造等一律移出
- 考虑锁分段（如
ConcurrentHashMap的分段桶）或无锁结构（如基于 CAS 的队列），把“大锁”拆成多个小范围互斥
验证比假设更可靠：用工具暴露真实问题
靠人工 review 很难发现竞态和死锁，尤其在复杂调用链中。必须依赖工程化手段：
- 静态检查：启用 IDE 的并发警告（如 IntelliJ 的 “May expose internal representation”）、SonarQube 规则、Clang ThreadSanitizer 编译选项
- 动态检测：Java 可开启
-XX:+UnlockDiagnosticVMOptions -XX:+PrintConcurrentLocks查看锁持有情况；Linux 下用perf record -e lock:lock_acquired分析锁热点 - 压力测试：用 JMeter / ghz / wrk 模拟高并发，并注入随机延迟（如
Thread.sleep(1-5ms)）放大时序敏感路径 - 混沌工程：在测试环境随机 kill 线程、模拟网络分区、暂停 GC，观察状态是否自洽、能否自动恢复
