Java并发安全与资源共享详解

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Java共享资源与并发安全详解》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

ArrayList线程不安全因其方法无同步控制，多线程并发add可能引发扩容竞态，导致ArrayIndexOutOfBoundsException、数据丢失或ConcurrentModificationException。

为什么多个线程访问同一个 ArrayList 会出错

因为 ArrayList 不是线程安全的：它的 add()、remove()、get() 等方法内部没有同步控制。当两个线程同时调用 add()，可能触发底层数组扩容，而扩容过程涉及新建数组、复制元素、更新引用——若此时另一个线程正在读或写旧数组，就会出现 ArrayIndexOutOfBoundsException、数据丢失或 ConcurrentModificationException。

常见现象包括：集合大小比预期小、遍历时抛 ConcurrentModificationException、偶发 NullPointerException（因元素未完全写入）。

• 不要在多线程环境中直接共享裸 ArrayList、HashMap、HashSet
• 如果只读不写，且初始化完成后不再修改，可用 Collections.unmodifiableList() 包装
• 若需读多写少，优先考虑 CopyOnWriteArrayList；但注意它每次写操作都复制整个数组，不适合高频写场景

如何正确使用 synchronized 保护临界区

加锁本身不难，关键在于锁对象是否一致、粒度是否合理。错误做法是给每个方法加 synchronized，却用不同锁（如 this vs getClass()），导致实际没互斥。

典型问题：对共享资源的读写必须使用同一把锁；锁范围应刚好覆盖所有依赖该资源的操作，过大会降低并发度，过小则失去保护。

• 实例方法上加 synchronized，等价于用 this 作锁；静态方法加 synchronized，等价于用 MyClass.class 作锁
• 若需细粒度控制（例如只锁某个字段），显式使用 synchronized(lockObj)，且确保所有访问路径都用同一个 lockObj
• 避免在同步块内调用外部可重入的方法（如回调、I/O），以防死锁或锁持有时间过长

ReentrantLock 比 synchronized 多了什么

ReentrantLock 提供更灵活的锁控制能力，但不是“更高级就该默认用它”。它适合需要尝试获取锁、可中断等待、或按特定顺序释放多个锁的场景。

容易忽略的点：ReentrantLock 必须手动 lock() 和 unlock()，且 unlock() 必须放在 finally 块中；否则一旦异常跳出，锁永远无法释放。

• 用 lock.tryLock() 可避免无限等待，适合超时控制或避免死锁检测
• lock.lockInterruptibly() 允许线程被 interrupt() 中断，而 synchronized 不响应中断
• 不要在 ReentrantLock 的 lock() 和 unlock() 之间跨方法调用，除非你明确掌控整个调用链的异常路径

ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // 访问共享资源
} finally {
    lock.unlock(); // 必须放在这里
}

原子变量（AtomicInteger 等）能替代锁吗

能，但仅限于单个变量的简单操作，比如计数器、状态标志、序列号生成。它们底层依赖 CPU 的 CAS（Compare-And-Swap）指令，无锁且高效。

不能替代锁的场景：多个变量需要保持一致性（如银行转账：从 A 扣款 + 给 B 加款），或操作逻辑复杂（如先查再改再存），这时 CAS 无法保证整体原子性。

• AtomicInteger 的 incrementAndGet() 是原子的；但 i++（即 get() + 1 再 set()）不是，必须用原子方法
• 注意 lazySet() 和 set() 的内存语义差异：lazySet() 不保证后续读操作立即看到，适合写后极少读的场景（如统计上报）
• 不要试图用多个原子变量拼出复合操作的安全性——这通常意味着你需要真正的锁或事务机制

并发安全的核心不在“用了什么工具”，而在“是否识别出所有共享状态，以及是否对所有访问路径施加了一致的同步策略”。很多 bug 出现在边界情况：比如一个线程刚初始化完对象，另一个线程就通过某种间接引用访问到了它——此时连锁对象本身都还没准备好。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。