Что может привести к блокировке программы на мониторе, которому он принадлежит? - PullRequest
1 голос
/ 21 сентября 2011

Недавно у меня была проблема с тремя отдельными серверами, на которых выполнялся один и тот же код, и все они имели одинаковые симптомы. Это серверы REST / JSON большого объема, которые используют json-lib для создания ответов 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], по-видимому, не ссылается на идентификатор объекта и не отображается нигде в трассировке стека.

Я обнаружил точно такую ​​же проблему здесь без ответа, и этот старый вопрос SO , в котором говорится, что это ошибка JVM, вызванная неправильным назначением монитора одному из ожидающих потоков. Я не совсем уверен, что понимаю, как поток может быть помечен как блокирующий монитор, но фактически не предоставленный монитору, но имеет смысл, что эти операции могут быть отдельными, и ошибка в JVM вызывает проблему после назначения блокировки, но перед назначением монитора (хотя я всегда думал о них как об одном и том же).

Ява версия Java, которую я использую:

Java-версия "1.6.0_18" Java (TM) SE Runtime Environment (сборка 1.6.0_18-b07) Java HotSpot (TM) 64-разрядная серверная виртуальная машина (сборка 16.0-b13, смешанный режим)

О

CentOS выпуск 5.2 (финал) Версия ядра: 2.6.18-194.17.4.el5xen

Это действительно просто ошибка JVM или есть что-то еще, на что я должен обратить внимание?

Edit:

Версия commons-beanutils, которую мы использовали, была 1.7. С тех пор мы обновились до версии 1.8, чтобы посмотреть, решит ли она проблему.

1 Ответ

0 голосов
/ 21 сентября 2011

Похоже, это связано с этой ошибкой

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

При первой загрузке класса блок загрузки и статический блок являются поточно-ориентированными. Если при загрузке класса возникает проблема, это не всегда очевидно.

...