问题标签 [reentrantlock]

在java JRE中我看到了代码

为什么锁定被捕获到私有变量？我希望简单

我查看了 ReentrantLock 的 Java API，我可以看到synchronized关键字没有使用同步。是否在 AbstractQueuedSynchronizer 中的以下方法中（ReentrantLock 在尝试获取锁时引用）同步对象？由于compareAndSwapInt是本机方法，是否在本机级别/代码进行同步？

我试图通过阻止异步尝试使用 RentrantLock 修改实体的给定实例（由键标识）来实现一个类以在我的 java 应用程序中强制并发。目标是阻止/排队多个并发尝试修改对象的给定实例，直到先前的线程完成。该类以通用方式实现这一点，允许任何代码块获得锁并在完成后释放它（与 RentrantLock 语义相同），并添加了仅阻塞线程试图修改对象的相同实例（如标识通过一个键），而不是阻止所有进入代码块的线程。

这个类提供了一个简单的结构，允许只为一个实体的一个实例同步一个代码块。例如，如果我希望为来自 id 为 33 的用户的所有线程同步一段代码，但我不希望来自任何其他用户的线程被服务用户 33 的线程阻塞。

该类实现如下

此类使用如下：

问题是它不能完美地工作。在非常高的并发负载下，仍然存在一些具有相同键的多个线程没有同步的情况。我已经通过并进行了相当彻底的测试，无法弄清楚为什么/在哪里会发生这种情况。

有并发专家吗？

我正在开发一个可点击的小部件。我想使用一个静态的 java.util.concurrent.locks ReentrantLock 所以每次只调用一次小部件逻辑。

但我担心的是，在非常罕见的情况下，锁可能不会被释放，因为它会因为 10 秒的生命周期窗口而被预先杀死。

使用 ReentrantLock 是否存在反对意见？释放锁的最佳方法是什么？

或者也许有一个Android选项可以只运行单线程？

目前我正在考虑在finally块或finalize方法（哎哟）中释放onReceive结束时的锁。

我正在实现一个可以读写数据的数据库。对于并发问题，我需要实现锁。通常，ReentrantReadWriteLock 会让写在读之前执行。我怎么能反过来？有没有一种方法可以在写线程执行之前读取？

我想编写一段可重用的代码，以便在将任务提交到执行程序服务时允许等待条件。如果队列中的任务过多，则有很多巧妙的阻塞方式的实现，例如这里

我需要一个执行器来评估所有等待的线程，每次任务完成。为了决定是否允许在 atm 提交任务，必须考虑所有活动任务的当前状态。我想出了以下解决方案，它不必针对多个提交者或同时执行的高级任务进行扩展。

问题：以下代码可以安全使用，还是我遗漏了一些缺陷？实现aquireAccess方法的人ConditionEvaluator<T>必须确保查询线程状态的方式是线程安全的，但实现者不需要保护对 activeTasks 集合的迭代。这是代码：

问题：代码可以改进吗？

我试图了解是什么让并发锁如此重要，如果可以使用synchronized (this). 在下面的虚拟代码中，我可以执行以下任一操作：

1. 同步整个方法或同步易受攻击的区域 ( synchronized(this){...})
2. 或使用 ReentrantLock 锁定易受攻击的代码区域。

代码：

以下是典型的读写器模式（读多写少）

我想知道是否可以优先考虑作者和读者？例如，如果其他线程不断持有读锁，通常 writer 可能会等待很长时间（可能永远），所以是否可以让 writer 具有更高的优先级，所以每当 writer 到来时，它可以被认为是高优先级（跳线）之类的。

我正在编写自己的 BlockingQueue 实现以供练习。我试图避免对方法使用同步关键字。相反，我想使用 ReentrantLock。

编写此实现的最佳方法是什么？我不是 Java 忍者，如果有人能在此处查明我的代码中的错误并提出更好的实现方法，我将不胜感激。

谢谢你的时间！

我根据此页面上的示例制作了一个线程池。在工作线程中，我们有一个永远不会让线程死亡的无限循环，以及当没有工作要做时暂停线程的 wait() 方法调用：

事实是，如果队列为空，则r = (Runnable) queue.removeFirst();可以抛出一个 RuntimeException 。NoSuchElementException并且当在该行上引发此类异常时，当前持有互斥锁的线程将死亡，并且池会泄漏线程。当线程死亡时，互斥锁似乎被释放。

但是，如果您不使用 defaultsynchronized关键字来同步队列，而是使用ReentrantLockto 锁定和发送Condition信号和等待，则当前持有互斥锁的线程在意外中断时似乎不会释放锁定。

因此，就我而言，当我在 Threads 选项卡下检查 JVisualVM 时，我可以看到AWT-EventQueue-0线程正在等待Thread-1释放互斥锁。但是 Thread-1 在运行任务的途中死了，并且意外终止（RuntumeException），并且互斥锁似乎没有被释放。

我的问题：

1)如果持有它的线程意外终止，是否不会释放ReentrantLocks ？

2）上面的代码片段之间while (queue.isEmpty()) {有什么区别吗？if (queue.isEmpty()) {我看不出有什么区别，因为线程在这两种情况下都会等待。但我认为它在使用时的行为有所不同if（比如如果多个线程会影响队列）。

EDIT
Java Concurrency in Practice 状态：

由于所有这些原因，当您从等待中醒来时，您必须再次测试条件谓词，如果尚未为真，则返回等待（或失败）。由于您可以在条件谓词不为真的情况下反复唤醒，因此您必须始终在循环内调用等待，在每次迭代中测试条件谓词。

看看我在上面的代码中的编辑，现在代码应该是正确的，如 Java Concurrency in Practice 中所述。