线程竞争是并发环境下多个线程同时访问并修改同一共享可变资源且缺乏同步时的固有风险，表现为数据丢失、脏读、逻辑错乱及性能下降，需依场景选用原子类、读写锁、ThreadLocal或ConcurrentHashMap等策略应对。
Java线程竞争，是指多个线程同时访问并试图修改同一共享资源（如变量、对象、文件、数据库连接等），而缺乏有效协调机制时产生的冲突状态。它不是“出错了才发生”，而是并发环境下只要存在共享+可变+非同步，就天然存在竞争风险。核心问题在于操作的非原子性、内存可见性缺失和执行顺序不确定性。
线程竞争的典型表现
这些现象往往不是报错，而是“结果不对”或“行为飘忽”，容易被误判为偶发bug：
- 数据丢失或覆盖：比如两个线程对 int count 执行 count++，预期+2，实际只+1——因为都读了旧值0，各自加1后都写回1。
- 脏读或过期值：线程A更新了变量，线程B仍读到旧值，因JVM工作内存未及时刷新主内存（可见性问题）。
- 逻辑错乱：如银行转账中，“检查余额→扣款”看似连贯，但中间被其他线程插队导致透支；或单例双重检测锁因指令重排序失效。
- 性能陡降但无明显错误：大量线程在同一个锁上排队等待（锁争用），CPU花在上下文切换而非业务计算上。
关键解决策略与实操要点
不是“加个synchronized就万事大吉”，而是按场景选对工具、控好粒度：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 缩小临界区，只锁真正共享的部分：避免把耗时IO、网络调用、复杂计算包进synchronized块；只包裹“读-改-写”那几行核心代码。
- 优先用原子类替代基础变量：对计数器、开关标志等简单状态，用 AtomicInteger、AtomicBoolean 等，底层靠CAS实现无锁并发，性能高且简洁。
- 读多写少场景用读写锁：ReentrantReadWriteLock 允许多个线程并发读，写操作独占——比全用synchronized提升吞吐量数倍。
- 避免共享，转向线程私有：能用局部变量就不用实例变量；需跨方法传递状态时，考虑 ThreadLocal 存储每个线程专属副本（注意及时 remove 防内存泄漏）。
- 集合操作换并发专用类：别用 Collections.synchronizedMap 包裹 HashMap，直接用 ConcurrentHashMap；遍历时不怕 ConcurrentModificationException。
容易被忽略的细节
很多问题不是没加锁，而是锁得“不对路”：
立即学习“Java免费学习笔记（深入）”；
- 用 new Object() 作为锁对象时，若每次新建实例，等于没锁——必须是同一个对象引用。
- synchronized(this) 锁的是当前实例，但若该对象被外部暴露，别人也能拿它加锁，可能引发意外阻塞或死锁。
- volatile 只解决可见性和禁止重排序，不保证原子性——i++ 这种操作即使加了 volatile 依然会丢数据。
- 锁升级、偏向锁撤销等JVM优化虽自动发生，但在高竞争下可能退化为重量级锁，此时应关注是否设计本身导致过度争抢。
基本上就这些。线程竞争不复杂，但容易忽略临界区边界和内存模型细节。抓住“共享、可变、非同步”三个关键词，再结合具体读写比例和操作复杂度选方案，就能稳住大部分并发场景。
