Как выяснить, почему нить застряла?

Question

Как выяснить, почему нить застряла?

1

Я вижу этот поток в моем jstack, который, кажется, не движется вообще. Любые указатели на то, как понять, почему он застрял? Я не вижу никаких замков или чего-то еще, единственной подозрительной вещью является ссылка "Object.wait()".

"main" prio=10 tid=0x00007f3a8000b000 nid=0x942 in Object.wait() [0x00007f3a89539000]
   java.lang.Thread.State: RUNNABLE
        at org.joda.time.DateTimeZone.<clinit>(DateTimeZone.java:95)
        at org.joda.time.format.DateTimeFormatter.withZoneUTC(DateTimeFormatter.java:301)
        at com.amazonaws.auth.AWS4Signer.<clinit>(AWS4Signer.java:44)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
        at java.lang.Class.newInstance0(Class.java:372)
        at java.lang.Class.newInstance(Class.java:325)
        at com.amazonaws.auth.SignerFactory.createSigner(SignerFactory.java:121)
        at com.amazonaws.auth.SignerFactory.lookupAndCreateSigner(SignerFactory.java:107)
        at com.amazonaws.auth.SignerFactory.getSigner(SignerFactory.java:80)
        at com.amazonaws.AmazonWebServiceClient.computeSignerByServiceRegion(AmazonWebServiceClient.java:311)
        at com.amazonaws.AmazonWebServiceClient.computeSignerByURI(AmazonWebServiceClient.java:284)
        at com.amazonaws.AmazonWebServiceClient.setEndpoint(AmazonWebServiceClient.java:160)

Кроме того, строка 95 в DateTimeZone.java в верхней части стека:

   public static final DateTimeZone UTC = new FixedDateTimeZone("UTC", "UTC", 0, 0);

Есть еще один поток, который также застрял в подобном месте:

"FeatureManagerService" daemon prio=10 tid=0x00007f3a8056a800 nid=0x94f in Object.wait() [0x00007f3a84151000]
   java.lang.Thread.State: RUNNABLE
        at com.amazonaws.util.DateUtils.<clinit>(DateUtils.java:35)
        at com.amazonaws.services.s3.internal.ServiceUtils.<clinit>(ServiceUtils.java:59)
        at com.amazonaws.services.s3.internal.S3Signer.sign(S3Signer.java:123)
        at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:348)
        at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:245)
        at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3711)
        at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3664)
        at com.amazonaws.services.s3.AmazonS3Client.listObjects(AmazonS3Client.java:620)
        at com.amazonaws.services.s3.AmazonS3Client.listObjects(AmazonS3Client.java:603)

И DateUtils.java:35:

private static final DateTimeZone GMT = new FixedDateTimeZone("GMT", "GMT", 0, 0);

Я уже пробовал изучать его с помощью jvisualvm/jhat, но на самом деле не очень далеко.

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

Любая помощь будет оценена!

Благодарю!

Обновление с использованием смешанного режима в jstack, похоже, дает более глубокое понимание - он ждет pthread_cond_wait:

----------------- 2370 -----------------
0x00007f3a89115414      __pthread_cond_wait + 0xc4
0x00007f3a8833a03c      _ZN13ObjectMonitor4waitElbP6Thread + 0x7dc
0x00007f3a88117fbb      _ZN13instanceKlass15initialize_implE19instanceKlassHandleP6Thread + 0x36b
0x00007f3a881182ca      _ZN13instanceKlass10initializeEP6Thread + 0x6a
0x00007f3a8814d3f3      _ZN18InterpreterRuntime4_newEP10JavaThreadP19constantPoolOopDesci + 0x143
0x00007f3a7d01d9ee      * org.joda.time.DateTimeZone.<clinit>() bci:0 line:95 (Interpreted frame)
0x00007f3a7d0004f7      <StubRoutines>
...

naumcho 02 сен. 2014, в 17:58

Источник

0

Есть другие темы, делающие вещи? Есть свалка потока?
ssnobody 02 сен. 2014, в 15:55
0

Есть еще несколько тем - что мне искать?
naumcho 02 сен. 2014, в 16:04
0

@ssnobody обнаружил, что другой поток застрял перед созданием FixedDateTimeZone
naumcho 02 сен. 2014, в 16:15
0

Я полагаю, что большинство зависаний в java вызвано либо бесконечными циклами, либо ожиданием блокировок. Исследование синхронизированных методов или блоков, которые могли бы получить эти блокировки, было бы моим первым проходом, но также может быть полезно просто получить их список. Этот листинг должен быть найден в подпрограмме дампа подкомпонента LK для дампа потока / javacore. Кроме того, javadump (инструмент, который генерирует дамп потока) иногда может сразу же диагностировать сам тупик.
ssnobody 02 сен. 2014, в 16:16
0

Рад, что вы поняли это!
ssnobody 02 сен. 2014, в 16:18
0

@ssnobody Я не вижу каких-либо блокировок или синхронизаций между этими двумя потоками, они должны быть потоко-безопасными. Единственное, что выглядит странно, это то, что они оба застряли перед инициализацией статического объекта в одно и то же время, но я не вижу никаких блокировок. Как мне посмотреть подкомпонент LK?
naumcho 02 сен. 2014, в 16:26
0

См. Publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/… и publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/…
ssnobody 02 сен. 2014, в 16:29
0

Я пробовал это, но я не получаю информацию о LK - похоже, что это может быть что-то специфическое для IBM JVM, тогда как я использую HotSpot JVM.
naumcho 02 сен. 2014, в 17:41
0

Может ли это быть ошибкой? См. «Дедлок в статической инициализации DateTimeZone / FixedDateTimeZone» на github.com/JodaOrg/joda-time/issues/171 (надеюсь, вы не были тем, кто на самом деле сообщил об этом, поскольку он совсем недавно)
Christophe Augier 03 сен. 2014, в 16:04
0

@ChristopheAugier Да, это именно то, что это такое!
naumcho 03 сен. 2014, в 18:31
0

@ChristopheAugier, приятные люди из AWS помогли поднять проблему, которую вы только что обнаружили с Джодой, помогая мне разобраться в этом
naumcho 03 сен. 2014, в 18:42

Показать ещё 9 комментариев

Теги:

java

debugging

stack-trace

jstack

jodatime

2 ответа

Ещё вопросы

Есть другие темы, делающие вещи? Есть свалка потока?
Есть еще несколько тем - что мне искать?
@ssnobody обнаружил, что другой поток застрял перед созданием FixedDateTimeZone
Я полагаю, что большинство зависаний в java вызвано либо бесконечными циклами, либо ожиданием блокировок. Исследование синхронизированных методов или блоков, которые могли бы получить эти блокировки, было бы моим первым проходом, но также может быть полезно просто получить их список. Этот листинг должен быть найден в подпрограмме дампа подкомпонента LK для дампа потока / javacore. Кроме того, javadump (инструмент, который генерирует дамп потока) иногда может сразу же диагностировать сам тупик.
@ssnobody Я не вижу каких-либо блокировок или синхронизаций между этими двумя потоками, они должны быть потоко-безопасными. Единственное, что выглядит странно, это то, что они оба застряли перед инициализацией статического объекта в одно и то же время, но я не вижу никаких блокировок. Как мне посмотреть подкомпонент LK?
См. Publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/… и publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/…
Я пробовал это, но я не получаю информацию о LK - похоже, что это может быть что-то специфическое для IBM JVM, тогда как я использую HotSpot JVM.
Может ли это быть ошибкой? См. «Дедлок в статической инициализации DateTimeZone / FixedDateTimeZone» на github.com/JodaOrg/joda-time/issues/171 (надеюсь, вы не были тем, кто на самом деле сообщил об этом, поскольку он совсем недавно)
@ChristopheAugier Да, это именно то, что это такое!
@ChristopheAugier, приятные люди из AWS помогли поднять проблему, которую вы только что обнаружили с Джодой, помогая мне разобраться в этом

Christophe Augier · Answer 1 · 2014-09-05T14-19-00.000Z

Как было найдено @naumcho, это оказалось ошибкой (https://github.com/JodaOrg/joda-time/issues/171).

Основываясь на предоставленной информации (трассировки стека двух разных нитей + исходная строка), можно было заподозрить тупик, потому что оба потока пытаются создать экземпляр нового объекта с FixedDateTimeZone типом FixedDateTimeZone.

Следующий шаг, чтобы подтвердить, что будет использовать GDB для проверки кадров стека вокруг __pthread_cond_wait().

alamar · Answer 2 · 2014-09-02T13-55-00.000Z

Может быть, это не застряло. Он просто вызывает новую дату DateTimeZone() в цикле, а конструктор выполняет некоторые вычисления. Каждый раз, когда вы смотрите на этот поток, он находится внутри DateTimeZone(), но каждый раз он отличается от DateTimeZone().

Который затем отбрасывается. Случилось со мной несколько раз.

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