问题标签 [reentrantreadwritelock]

我的应用程序部署在带有 java 6 update 30 的 Weblogic 10.3.5 上。执行此代码行时遇到以下错误：

在类加载期间初始化锁：

缓存是：

突然抛出了 IllegalMonitorStateException：

我在这里阅读了与这种情况类似的描述。

有人知道为什么会这样吗？

爪哇大师，

目前我们有一个经常HashMap<String,SomeApplicationObject>被读取和偶尔修改的文件，我们遇到了在修改/重新加载期间，读取操作返回的问题，null这是不可接受的。

为了解决这个问题，我有以下选项：

A. 使用ConcurrentHashMap

这看起来像是第一个选择，但我们正在谈论的操作是reload()- 意味着clear()后跟replaceAll()。因此，如果Map阅读 postclear()和 prereplaceAll()它返回 null 这是不可取的。即使我synchronize这并不能解决问题。

B. 基于 ReentrantReadWriteLock创建另一个实现

我将在操作Write Lock前创建获取reload()。这似乎更合适，但我觉得必须有一些可用的东西，我不需要重新发明轮子。

最好的出路是什么？

编辑是否已经有任何具有此类功能的收藏？

据说，这ReentrantReadWriteLock是为一位作家和多位读者准备的。

然而，读者应该等到缓冲区中存在一些数据。

那么，要锁定什么？

我创建了如下并发对象：

现在在写方法我做：

但是如何写一个读者呢？它应该只获取readLock吗？但它怎么能等待信号呢？如果它还需要一个writeLock，那么读/写锁定的至高无上的地位在哪里？

如果它们仅受保护，如何确保所需的变量在读取期间不会改变writeLock？

队列与任务不匹配

这是关于ReentrantReadWriteLock.

请向我解释一下合同。我无法弄清楚是否包含在ReentrantReadWriteLock某种相关的两个锁？或者这些只是两个普通锁的捆绑？

我有一个比较笼统的问题，请指教。

我有一个小服务程序。

这个 servlet 有私有字段。

私有字段是一种元数据的东西（公共类元数据{//bla-bla-bla}）。

处理GET请求时，此元数据用于执行某些操作。

我想在同一个 servlet 中实现 POST 方法。用户上传文件并更新元数据字段。

问题：使用一个 servlet 实例在多个 web 线程之间共享元数据对象并发访问此私有字段。POST 方法操作（更新元数据对象）会导致元数据状态不一致，并发 GET 请求可能会失败。

问题：在 GET 请求运行时更新元数据对象的最佳方法是什么？

虚拟解决方案：

1. 在每个 GET 请求期间，一开始

2. 同步元数据对象并将其克隆在一个块中，然后释放它。

3. 并发 GET 请求与一致的元数据对象的克隆版本一起使用。

4. 在每个 POST 请求期间。

5. 同步元数据对象并更新其字段。

6. 释放元数据对象。

请建议或批评。

正如标题所说，很好奇当前线程崩溃时读写锁会发生什么。

我们绝对可以在 finally 块中解锁以防止任何突然出现。但是如果 readLock.lock() 语句崩溃了，锁会自动释放吗？

谢谢，

使用模式源于以下原因：

1. 如果条件不存在，我需要读取线程来等待数据。

2. 读锁不支持条件，所以条件应该取自写锁。

3. 由于读线程会等待条件，它也应该获得写锁来等待。

我在课堂上有以下锁定义：

在我的作家方法中，我有以下模式：

在我的阅读方法中，我有以下模式

上面的模式正确吗？

问题是如果读者是可重入的，即多次锁定读，则释放代码不起作用，读者在获得写锁的那一行挂起。

我对RentrantReadWriteLock的理解是，它允许同时读取很多次但只允许一次写入。

当我们尝试获取读锁时，文档状态

这里是什么held意思？

• 另一个线程请求了写锁并且执行比写？

或者

• 上述情况以及另一个线程已请求写锁但正在等待获取它的情况。

因为当请求写锁时，如果

• 别人有写锁
• 别人有读锁

从写锁定文档：

因此，当一个线程在请求​​它之后等待写锁时，我只想了解读取锁调用的后续行为。他们是否让写锁的请求等待更长的时间？

在 Java 的实现锁中，没有办法将锁从读锁自动升级为写锁。例如，以下代码片段失败

写锁获取必须等待所有读锁完成，以便它知道它没有覆盖读者可能正在读取的数据。那很糟。所以解决方法是做这样的事情：

但这并不理想 - 当您解锁读取和拿起写入时，有人可能会去做一些事情。现在，无论如何仔细检查这些条件可能是一个好主意，但仍然 - 它很难看。

现在通常，当您获得锁时，您希望强制代码等待它实际获得，然后再执行您正在做的事情。您不想只相信您的锁定机制，它会在您开始弄乱数据之前为您提供锁定。

但是为什么它会强迫你从你发出想要锁的信号到你真正读到等待时停止执行呢？例如，为什么它不能允许这样的事情：

所以从某种意义上说，当前的锁功能可以被理论化为它们都是同时完成的，比如

什么样的设计决策会让他们不允许某种延迟的意图锁定？像我根本没有看到的那样的锁设计是否存在严重问题？

我正在尝试实现一个资源处理程序类，该类将资源（字符串，存储在数组中）分配给多个客户端，这些客户端可以尝试获取一组资源的锁并通过 lock 方法给出的 ID 解锁它们。

我正在尝试使用公平的 ReentrantReadWriteLock-s，每个资源一个。

我只看到客户端的日志。

有几个问题，有时一个线程不会停止请求和获取资源，有时会发生死锁，有时释放锁失败。任何提示表示赞赏。