
本文深入探讨了java中细粒度并发二叉搜索树实现过程中常见的死锁问题,特别是由于`reentrantlock`的重复获取和不当释放导致的并发故障。通过分析错误的锁定模式,文章揭示了死锁的根源,并提供了基于“手递手”锁(hand-over-hand locking)策略的正确解决方案。教程强调了`reentrantlock`的正确使用、锁粒度选择以及并发编程中异常安全的重要性,旨在帮助开发者构建健壮、高效的并发数据结构。
在多线程环境中实现二叉搜索树(BST)等数据结构时,为了保证数据的一致性和并发访问的正确性,需要引入适当的同步机制。细粒度锁(fine-grained locking)是一种常见的策略,它通过锁定树的特定节点或路径,允许不同线程同时操作树的不同部分,从而提高并发性能。其中一种实现方式是“手递手”锁(hand-over-hand locking)或“锁耦合”(lock-coupling),其核心思想是线程在遍历树时,先获取下一个节点的锁,然后再释放当前节点的锁,以确保在移动到下一个节点时,该节点已经被安全地锁定,防止其他线程在当前线程移动前修改该节点或其子树。
然而,细粒度锁的实现往往复杂且容易出错,稍有不慎就可能导致死锁、活锁或数据不一致等问题。本文将通过分析一个具体的并发二叉搜索树实现尝试,揭示其死锁的根源,并提供正确的解决方案。
考虑以下Java并发二叉搜索树的insertHelper方法片段,它尝试使用ReentrantLock实现“手递手”锁:
class BST {
// ... 其他成员变量和构造函数 ...
Lock leftLock = new ReentrantLock();
Lock rightLock = new ReentrantLock();
void insertHelper(int key, int lose, Lock prevLock) {
// ... 其他逻辑 ...
if (key < this.key) {
leftLock.lock(); // 第一次获取leftLock
if (left == null) {
left = new BST(key, lose);
leftLock.unlock();
prevLock.unlock();
} else {
leftLock.lock(); // 第二次获取leftLock
prevLock.unlock();
left.insertHelper(key, lose, leftLock);
}
} else {
rightLock.lock(); // 第一次获取rightLock
if (right == null) {
right = new BST(key, lose);
rightLock.unlock();
prevLock.unlock();
} else {
// prevLock.unlock(); // 此处也存在逻辑问题,但死锁主要由重复lock引起
right.insertHelper(key, lose, rightLock);
}
}
}
}在上述代码中,当key < this.key且left子节点不为空时,程序会进入else分支。此时,leftLock在进入if (key < this.key)块时已经通过leftLock.lock()获取了一次。然而,在else分支内部,又一次调用了leftLock.lock()。
立即学习“Java免费学习笔记(深入)”;
ReentrantLock是可重入的,这意味着同一个线程可以多次获取同一个锁而不会阻塞自己。每次成功获取锁都会增加锁的内部计数器。相应地,只有当unlock()方法被调用与lock()方法的调用次数相同时,锁才会被完全释放,其他线程才能获取该锁。
在本例中,如果线程进入else分支,leftLock的内部计数器会变为2。然而,在left.insertHelper(key, lose, leftLock)的递归调用中,leftLock作为prevLock被传递。当递归调用最终完成时,prevLock.unlock()(即leftLock.unlock())只会将锁计数器减1。这意味着leftLock仍然被当前线程持有,其计数器为1。其他任何试图获取leftLock的线程都将永远阻塞,从而导致死锁。rightLock分支也存在同样的问题。
此外,原始代码中insertHelper方法开头的if (!prevLock.tryLock()) { System.out.println("ERROR"); return; } 逻辑也值得商榷。如果tryLock()失败,线程只是简单地返回,这意味着插入操作可能不会完成,并且没有提供任何回退或重试机制,这在生产环境中通常是不可接受的。
解决死锁的关键在于确保lock()和unlock()调用始终成对且逻辑正确。在“手递手”锁策略中,正确的模式是:获取子节点锁,然后释放父节点锁。
修正后的insertHelper方法应该避免在同一路径上重复获取同一个锁。当left或right子节点不为空时,我们已经持有了其父节点的锁(即prevLock),并且在进入当前节点处理逻辑时,我们已经获取了当前节点的锁。如果我们要进一步向下遍历,应该先获取下一个目标子节点的锁,然后释放当前节点的锁。
以下是修正后的insertHelper方法:
class BST {
int key;
int val;
BST left = null;
BST right = null;
Lock leftLock = new ReentrantLock();
Lock rightLock = new ReentrantLock();
BST(int key, int val) {
this.key = key;
this.val = val;
}
void insertHelper(int key, int lose, Lock prevLock) {
// 确保锁在任何情况下都能被释放,使用try-finally块是更健壮的做法
// 这里为了演示核心逻辑,暂时省略try-finally,但在实际生产代码中强烈推荐使用
// prevLock.lock(); // 假设prevLock在调用insertHelper前已被锁定,这里无需再次lock
try {
if (key == this.key) {
this.val += lose;
// 找到目标节点,完成操作后释放prevLock
return; // 最终会在外部的finally块或明确的unlock处释放
} else if (key < this.key) {
leftLock.lock(); // 获取左子节点锁
try {
if (left == null) {
left = new BST(key, lose);
return; // 节点已插入,返回
} else {
// 左子节点存在,释放当前节点的锁(prevLock),继续递归
// 注意:这里的prevLock是当前节点的锁,而不是leftLock
// 递归调用会处理leftLock的释放
left.insertHelper(key, lose, leftLock);
return;
}
} finally {
// 如果在else分支中,leftLock作为prevLock传入递归,
// 那么它会在递归的finally块中被释放。
// 如果在if (left == null) 分支中,leftLock在这里释放
if (left == null) { // 只有当left为null,且在此处创建新节点时,才在此释放leftLock
leftLock.unlock();
}
}
} else { // key > this.key
rightLock.lock(); // 获取右子节点锁
try {
if (right == null) {
right = new BST(key, lose);
return; // 节点已插入,返回
} else {
// 右子节点存在,释放当前节点的锁(prevLock),继续递归
right.insertHelper(key, lose, rightLock);
return;
}
} finally {
// 同理,只有当right为null,且在此处创建新节点时,才在此释放rightLock
if (right == null) {
rightLock.unlock();
}
}
}
} finally {
// 无论何种情况,确保在方法结束时释放prevLock
// 这里的prevLock是当前节点的父节点锁,或者根节点的锁
// 必须确保每次进入insertHelper时prevLock都被锁定,并在退出时释放
prevLock.unlock();
}
}
}为了使上述insertHelper方法能够正确工作,我们需要对RootBST类中的insert方法进行相应的调整,以确保prevLock的传递和初始锁的获取是正确的。
class RootBST {
Lock rootLock = new ReentrantLock(); // 根节点自身的锁
BST root = null;
void insert(int key, int lose) {
rootLock.lock(); // 锁定根节点
try {
if (root == null) {
root = new BST(key, lose);
} else {
root.insertHelper(key, lose, rootLock); // 传递根节点锁
}
} finally {
rootLock.unlock(); // 确保根节点锁被释放
}
}
}
class BST {
int key;
int val;
BST left = null;
BST right = null;
Lock leftLock = new ReentrantLock();
Lock rightLock = new ReentrantLock();
BST(int key, int val) {
this.key = key;
this.val = val;
}
void insertHelper(int key, int lose, Lock currentParentLock) {
// currentParentLock 是调用方传递进来的当前节点的父节点锁
// 在进入本方法时,我们已经持有了currentParentLock
// 我们的目标是获取当前节点自身的锁,然后释放currentParentLock
// 假设在调用insertHelper前,prevLock(即这里的currentParentLock)已经被锁定
// 我们需要获取当前节点对应的锁,但BST节点本身没有一个统一的“nodeLock”
// 而是通过leftLock/rightLock来保护其子节点。
// 这里的“手递手”策略需要更精细的设计。
// 修正后的逻辑:
// 在进入insertHelper时,currentParentLock是当前节点的父节点锁。
// 我们需要先判断是向左还是向右,然后获取相应的子节点锁,再释放currentParentLock。
if (key == this.key) {
this.val += lose;
// 找到目标节点,完成操作后释放currentParentLock
currentParentLock.unlock();
return;
} else if (key < this.key) {
leftLock.lock(); // 获取左子节点锁
try {
currentParentLock.unlock(); // 释放父节点锁
if (left == null) {
left = new BST(key, lose);
} else {
left.insertHelper(key, lose, leftLock); // 递归调用,传递左子节点锁
}
} finally {
// 如果在if (left == null) 分支中创建了新节点,则需要在这里释放leftLock
// 如果是递归调用,leftLock作为currentParentLock传入,会在递归的finally中释放
// 因此这里不需要额外的leftLock.unlock(),除非是创建新节点的情况。
// 但为了简洁和避免重复,让leftLock的释放统一由其作为currentParentLock时处理。
}
} else { // key > this.key
rightLock.lock(); // 获取右子节点锁
try {
currentParentLock.unlock(); // 释放父节点锁
if (right == null) {
right = new BST(key, lose);
} else {
right.insertHelper(key, lose, rightLock); // 递归调用,传递右子节点锁
}
} finally {
// 同理,rightLock的释放统一由其作为currentParentLock时处理。
}
}
}
}关键修正点:
在实现并发数据结构时,除了避免死锁,还需要考虑以下几点:
并发二叉搜索树的细粒度锁实现是一个经典的并发编程难题。本教程通过分析一个具体的死锁案例,揭示了ReentrantLock重复获取和不当释放是导致死锁的直接原因。正确的“手递手”锁定策略要求在获取子节点锁后立即释放父节点锁,并且必须确保lock()和unlock()调用成对出现,最好通过try-finally块来保证锁的释放。理解并正确应用这些原则对于构建健壮、高效的并发数据结构至关重要。在实际开发中,应仔细权衡锁的粒度、实现复杂性与性能之间的关系,并始终将异常安全放在首位。
以上就是Java并发二叉搜索树死锁问题深度解析与ReentrantLock正确实践的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号