核心内容摘要
价值投资者如何看待加密货币和数字资产
大家好我是锋哥。
今天分享关于【高频面试题Java死锁问题如何解决?】面试题。
希望对大家有帮助高频面试题Java死锁问题如何解决?死锁产生的四个必要条件缺一不可互斥Mutual Exclusion—— 锁只能被一个线程持有持有并等待Hold and Wait—— 持有至少一个锁同时等待另一个锁不可抢占No Preemption—— 锁只能由持有者主动释放循环等待Circular Wait—— 线程之间形成环形等待链解决死锁的核心思想破坏上面任意一个条件最常用的是破坏第4个其次是第2个。
实际开发中最有效的解决 预防手段按推荐优先级排序优先级方法核心思想适用场景缺点/代价代码示例关键点★★★★★固定锁获取顺序Lock Ordering破坏循环等待绝大多数业务场景需要提前规划锁的全局顺序所有线程都按相同顺序获取锁如按id排序★★★★☆使用带超时的锁tryLock破坏不可抢占 持有并等待锁竞争激烈、容易死锁的场景业务需处理获取失败的情况ReentrantLock.tryLock(时间, 时间单位)★★★★☆减小锁粒度 缩短锁持有时间减少持有并等待时间窗口锁保护范围过大的代码代码改动较大只在真正需要线程安全的地方加锁★★★☆☆避免嵌套锁 / 锁的交叉使用避免持有并等待老代码重构、复杂业务逻辑有时难以完全消除尽量把获取第二个锁的代码移出第一个锁范围★★★☆☆一次性申请所有资源破坏持有并等待资源有限且数量可知的场景实现复杂容易浪费资源类似银行家算法或先尝试获取所有锁★★☆☆☆使用更高级的并发工具从根本上减少显式加锁可以用新结构替换旧代码的地方学习成本、改造成本较高ConcurrentHashMap、CopyOnWrite、StampedLock、CompletableFuture 等★★☆☆☆死锁检测 自动恢复事后补救非首选极难避免死锁的遗留系统业务可能受损复杂ThreadMXBean.findDeadlockedThreads()最常用、最推荐的代码实践写法对比容易死锁的写法经典转账示例public void transfer(Account from, Account to, int amount) { synchronized (from) { synchronized (to) { // 嵌套锁 顺序不一致 → 极易死锁 // 转账逻辑 } } }推荐写法1固定锁顺序最常用、最安全public void transfer(Account from, Account to, int amount) { // 按账户ID的自然顺序加锁破坏循环等待 Account first from.getId() to.getId() ? from : to; Account second first from ? to : from; synchronized (first) { synchronized (second) { // 转账逻辑 } } }推荐写法2使用带超时的 ReentrantLock更灵活private final ReentrantLock lock1 new ReentrantLock(); private final ReentrantLock lock2 new ReentrantLock(); public boolean transferWithTimeout() { try { if (!lock
tryLock(5, TimeUnit.SECONDS)) { return false; // 或抛出自定义异常 } try { if (!lock
tryLock(5, TimeUnit.SECONDS)) { return false; } try { // 转账逻辑 return true; } finally { lock
unlock(); } } finally { lock
unlock(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } }快速记忆口诀生产环境最常说的一句话“要么锁的顺序全局统一要么加锁带超时其他都是辅助手段。
”最后几条生产环境铁律尽量避免在 synchronized 块里调用外部方法尤其是可能阻塞、IO、网络、加锁的方法锁保护的范围越小越好能用局部变量锁就别用对象锁能用java.util.concurrent包下的工具就尽量别手写 synchronized wait/notify定期做代码审查特别关注多个锁同时出现的业务逻辑