什么可能导致程序在它似乎拥有的监视器上被阻止？
我最近遇到了一个问题，三个独立的服务器运行相同的代码，并且都遇到相同的症状。这些是使用 json-lib 创建 JSON 响应的高容量 REST / JSON 服务器。服务器最终都会挂起，大多数线程都在等待一个特定的锁。持有该锁的线程都具有相同的基本外观：
"TP-Processor204" daemon prio=10 tid=0x00002aac40d85000 nid=0x6978 waiting for monitor entry [0x000000004dec8000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- locked <0x00002aaab230f970> (a java.lang.Class for org.apache.commons.beanutils.BeanUtilsBean)
at org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at net.sf.json.JSONObject._fromBean(JSONObject.java:918)
at net.sf.json.JSONObject.fromObject(JSONObject.java:168)
at net.sf.json.AbstractJSON._processValue(AbstractJSON.java:265)
at net.sf.json.JSONArray._processValue(JSONArray.java:2514)
at net.sf.json.JSONArray.processValue(JSONArray.java:2539)
at net.sf.json.JSONArray.addValue(JSONArray.java:2526)
at net.sf.json.JSONArray._fromCollection(JSONArray.java:1057)
at net.sf.json.JSONArray.fromObject(JSONArray.java:123)
at net.sf.json.AbstractJSON._processValue(AbstractJSON.java:237)
at net.sf.json.JSONObject._processValue(JSONObject.java:2808)
这是该线程持有的唯一锁。我曾尝试简单地用谷歌搜索监视器条目值所指的内容，但没有任何运气。对于此线程，值 [0x000000004dec8000] 似乎并不引用对象 id，并且它不会出现在堆栈跟踪中的其他任何位置。
我在这里发现了完全相同的问题，但没有答案这个较旧的SO问题说它是一个JVM由于未正确地将监视器分配给等待线程之一而导致的错误。我不完全确定我理解如何将一个线程标记为锁定监视器，但实际上并未给出监视器，但这些操作可能是分开的，并且 JVM 中的错误在分配锁后会导致问题，这是有道理的，但是在分配监视器之前（尽管我一直认为它们是同一件事）。
我使用的java版本是：
java版本“1.6.0_18” Java(TM) SE 运行时环境（版本 1.6.0_18-b07） Java HotSpot(TM) 64 位服务器 VM（内部版本 16.0-b13，混合模式）
：
CentOS 版本 5.2（最终版） 内核版本：2.6.18-194.17.4.el5xen
这真的只是一个 JVM 错误还是还有其他我应该研究的东西？
编辑：
我们使用的 commons-beanutils 版本是 1.7。我们已升级到 1.8，看看是否能解决该问题。
I recently had a problem with three separate servers running the same code all experiencing the same symptoms. These are high volume REST / JSON servers that use json-lib to create the JSON responses. The servers all eventually hang with most of the threads waiting on one particular lock. The thread holding that lock all had the same basic appearance:
"TP-Processor204" daemon prio=10 tid=0x00002aac40d85000 nid=0x6978 waiting for monitor entry [0x000000004dec8000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- locked <0x00002aaab230f970> (a java.lang.Class for org.apache.commons.beanutils.BeanUtilsBean)
at org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at net.sf.json.JSONObject._fromBean(JSONObject.java:918)
at net.sf.json.JSONObject.fromObject(JSONObject.java:168)
at net.sf.json.AbstractJSON._processValue(AbstractJSON.java:265)
at net.sf.json.JSONArray._processValue(JSONArray.java:2514)
at net.sf.json.JSONArray.processValue(JSONArray.java:2539)
at net.sf.json.JSONArray.addValue(JSONArray.java:2526)
at net.sf.json.JSONArray._fromCollection(JSONArray.java:1057)
at net.sf.json.JSONArray.fromObject(JSONArray.java:123)
at net.sf.json.AbstractJSON._processValue(AbstractJSON.java:237)
at net.sf.json.JSONObject._processValue(JSONObject.java:2808)
This is the only lock this thread is holding. I've tried briefly googling what the monitor entry value refers to, but didn't have any luck. For this thread, the value [0x000000004dec8000] doesn't appear to refer to an object id and it doesn't appear anywhere else in the stack trace.
I found the exact same issue here with no answer and this older SO question that says it's a JVM bug caused by not properly assigning the monitor to one of the waiting threads. I'm not completely sure I understand how the a thread could be marked as locking a monitor but not actually given the monitor, but it makes sense that those operations may be separate and a bug in the JVM causes a problem after assigning the lock but before assigning the monitor (although I've always thought of them as the same thing).
The java version I'm using is:
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
On:
CentOS release 5.2 (Final)
Kernel version: 2.6.18-194.17.4.el5xen
Is this really just a JVM bug or is there something else I should be looking into?
Edit:
The commons-beanutils version we were using was 1.7. We have since upgraded to 1.8 to see if it resolves the issue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这似乎与此错误有关
https://issues.apache.org/jira/browse /BEANUTILS-49
第一次加载类时，加载和静态块是线程安全的。如果加载类出现问题，这并不总是显而易见的。
This appears to be related to this bug
https://issues.apache.org/jira/browse/BEANUTILS-49
When loading a class for the first time, the loading and static block is thread safe. If there is a problem loading the class this is not always apparent.