Программное обнаружение мертвой блокировки в Java

Question

Программное обнаружение мертвой блокировки в Java

В основном модуль нельзя инстанцировать. Когда класс включает модуль, суперкласс прокси сгенерирован, который обеспечивает доступ ко всем методам модуля, а также методам класса.

модуль А может быть включен несколькими классами. Модули не могут быть наследованы, но эта "mixin" модель обеспечивает полезный тип "нескольких inheritrance". Пуристы OO не согласятся с тем оператором, но не позволяют чистоте помешать получению сделанного задания.

<час>

(Этот ответ, первоначально связанный с http://www.rubycentral.com/pickaxe/classes.html, но та ссылка и ее домен, больше не активен.)

56

java multithreading concurrency deadlock

задан oxbow_lakes 8 July 2009 в 22:07

6 ответов

Другие вопросы по тегам:

java multithreading concurrency deadlock

Похожие вопросы:

score 12 · Answer 1

Один полезный совет для расследования:

Если вы можете поймать приложение с поличным и подозревать возникновение взаимоблокировки, нажмите «Ctrl-Break» в окне консоли java.exe ( или "Ctrl- \" в Solaris / Linux). Jvm выведет текущий статус и трассировку стека всех потоков, обнаружит мертвые блокировки и точно опишет их.

Это будет выглядеть примерно так:

Full thread dump Java HotSpot(TM) Client VM (1.5.0_09-b03 mixed mode):

"[Test Timer] Request Queue" prio=6 tid=0x13d708d0 nid=0x1ec in Object.
    wait() [0x1b00f000..0x1b00fb68]
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Unknown Source)
    at library.util.AsyncQueue.run(AsyncQueue.java:138)
        - locked <0x02e70000> (a test.server.scheduler.SchedulerRequestQueue)

    ...

Found one Java-level deadlock:
=============================
"Corba service":
  waiting to lock monitor 0x13c06684 (object 0x04697d90, a java.lang.Object),
  which is held by "[Server Connection] Heartbeat Timer"
"[Server Connection] Heartbeat Timer":
  waiting to lock monitor 0x13c065c4 (object 0x0467e728, a test.proxy.ServerProxy), which is held by "Corba service"

Java stack information for the threads listed above:
===================================================
"Corba service":
    at test.proxy.ServerProxy.stopHBWatchDog(ServerProxy:695)
    - waiting to lock <0x04697d90> (a java.lang.Object)
    ...

score 2 · Answer 2

Возможно, вы захотите рассмотреть MTRAT IBM . В конце концов, профилактика лучше, чем лечение. Комплект для разработки многоядерного программного обеспечения также поставляется со средством обнаружения взаимоблокировок.

score 61 · Answer 3

Вы можете сделать это программно, используя ThreadMXBean , который поставляется с JDK:

ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] threadIds = bean.findDeadlockedThreads(); // Returns null if no threads are deadlocked.

if (threadIds != null) {
    ThreadInfo[] infos = bean.getThreadInfo(threadIds);

    for (ThreadInfo info : infos) {
        StackTraceElement[] stack = info.getStackTrace();
        // Log or store stack trace information.
    }
}

Очевидно, вам следует попытаться изолировать тот поток, который выполняет эту проверку взаимоблокировки - в противном случае, если это тупиковая ситуация в потоках, то проверка невозможна!

Между прочим, это то, что JConsole скрыто использует.

score 0 · Answer 4

Если вы хотите, чтобы это выполнялось во время выполнения, вы можете использовать для этого сторожевой таймер .

score 2 · Answer 5

Если вам не требуется программное обнаружение, вы можете сделать это через JConsole ; на вкладке ветки есть кнопка «обнаружить тупик». В JDK6 это обнаруживает блокировки как для встроенных мониторов, так и для juc Lock s

Запустите JConsole с помощью команды $ JAVA_HOM / bin / jconsole

score 1 · Answer 6

tempus-fugit также реализует его вместе с программным классом сброса потоков. Он реализован с использованием упомянутого выше механизма mbean и предлагает готовое решение супердуппера.

.