java - 什么可能导致程序在它似乎拥有的监视器上被阻止？

Question

我最近遇到了一个问题，三个独立的服务器运行相同的代码，并且都遇到相同的症状。这些是使用 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，并且它不会出现在堆栈跟踪中的其他任何位置。

我找到了exact same issue here没有答案，这个older SO question这表明这是由于未正确将监视器分配给等待线程之一而导致的 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，看看是否能解决该问题。

Answer 1

这似乎与此错误有关

https://issues.apache.org/jira/browse/BEANUTILS-49

第一次加载类时，加载和静态 block 是线程安全的。如果加载类时出现问题，这并不总是很明显。