软考中级必过？3道真题带你打通Java并发锁的核心逻辑

封面图

你是否还在为Java锁的死锁问题头疼？

很多考生在备考软考中级Java科目时，提到"并发编程"往往一脸茫然。"synchronized"和"ReentrantLock"到底有什么区别？死锁产生的四个条件怎么判断？在实际的并发场景下，如何选择合适的锁机制？这些问题不仅容易在选择题中出错，更会在案例分析题中成为扣分重灾区。

今天，我们就通过三道精选的历年真题，带你抽丝剥茧，彻底打通Java锁的核心逻辑。

真题一：synchronized的隐式锁与显式锁的抉择

题目回顾：某银行核心交易系统在处理高并发转账时，发现存在严重的性能瓶颈。开发人员引入了锁机制，但系统仍偶发出现"响应超时"。在代码审查中，有人建议将synchronized改为ReentrantLock，并尝试通过tryLock实现非阻塞策略。然而，测试环境却暴露出新的"资源泄露"问题。

核心解析：
这道题看似在考锁的选型，实则考察的是锁的公平性与锁的获取超时机制。

synchronized的隐式锁特性：synchronized是JVM层面的指令，由JIT编译器优化，具有内置的偏向锁、轻量级锁和重量级锁三种状态。它的特点是自动释放，即代码块执行完毕或异常抛出后，锁会自动解锁，不会发生资源泄露。
ReentrantLock的显式控制：ReentrantLock是API层面的锁，需要程序员手动调用unlock()方法。如果代码中出现异常而忘记释放锁，就会导致死锁或资源泄露。这正是题目中"响应超时"和"资源泄露"的根本原因。
tryLock的陷阱：tryLock确实可以防止线程阻塞，但它不会自动释放锁。如果主线程获取锁失败，而子线程在持有锁期间抛出异常，主线程持有的锁可能永远无法释放，导致系统假死。

落地建议：

对于简单场景，优先使用synchronized，享受JVM的优化红利。
对于复杂业务（如超时控制、公平性要求），使用ReentrantLock时，务必使用try-finally块确保锁的释放，或者使用tryLock配合超时机制。
绝对禁止在异常处理逻辑中忘记unlock()。

真题二：死锁的四大条件与预防策略

题目回顾：在一个多线程的数据库连接池管理中，线程A获取了锁L1后，尝试获取锁L2；线程B获取了锁L2后，尝试获取锁L1。最终系统卡死。请问这是典型的哪种死锁场景？如何从代码层面彻底预防？

核心解析：
这道题是软考中关于并发最经典的"坑"，考察的是死锁的四个必要条件。

互斥条件：资源一次只能被一个线程使用。
占有且等待：线程已持有资源，又在等待其他资源。
不可剥夺：线程持有的资源不能被其他线程强行抢走。
循环等待：存在一个线程资源的循环链。

死锁的预防策略（按优先级排序）：

打破循环等待（最有效）：设计统一的资源获取顺序。例如，规定所有线程必须先获取L1，再获取L2，杜绝交叉获取的可能。
设置超时机制：使用ReentrantLock的tryLock(timeout)，如果在规定时间内获取不到锁，主动放弃并重新尝试，避免线程无限期等待。
资源细粒度化：将大锁拆分为小锁，减少持有锁的时间。
减少锁的嵌套：尽量将临界区代码压缩，减少持有锁的时长。

落地建议：

在编写多线程代码时，强制规定全局资源获取顺序。
对于可能长时间阻塞的操作，必须引入超时判断。
使用日志工具监控线程状态，一旦发现线程处于"WAITING"状态且超过阈值，立即报警。

真题三：CAS（Compare-And-Swap）与ABA问题的解决

题目回顾：某电商秒杀系统使用CAS实现库存扣减，但偶尔出现"超卖"现象。经分析，库存数量从10变为11，再被扣减。请问问题出在哪？如何解决？

核心解析：
这道题考察的是并发编程中的可见性问题，特别是ABA问题。

CAS的局限性：CAS通过比较内存值与预期值来更新内存。如果线程A读取值为10，预期值为10，然后线程B将值修改为11，线程A再执行CAS时，预期值10与实际值11不匹配，CAS失败。如果此时线程C将值修改为10（回退），线程A再次执行CAS，预期值10与实际值10匹配，CAS成功，导致库存扣减错误（超卖）。
ABA问题的本质：值虽然回到了原始状态，但中间发生的状态变更（从10到11再到10）已经被忽略。

解决方案：

使用版本号：在数据旁维护一个版本号（version）。每次修改数据时，版本号+1。CAS比较的是"值+版本号"。即使值回到10，如果版本号不同，CAS也会失败。
使用Double-Checked Locking：在CAS失败后，二次检查并加锁。
使用原子类：如AtomicInteger，内部通常结合了CAS和版本号机制。

落地建议：