Содержание
Глохнет двигатель в начале движения хюндай солярис
Здравствуйте.
А после чего такое произошло, что то до этого ремонтировали? Нужно провести диагностику сканером, считать ошибки и проверить неисправные системы. Проверьте давление в топливной системе в первую очередь. Так же проверьте датчики абс. Если автомобиль на гарантии, то нужно обратиться к ОД, для устранения причины по гарантии. Если не на гарантии, то можно попробовать скинуть клемму аккумулятора минут на 10.
Вам будет полезна статья из нашей базы: https://blamper.ru/auto/wiki/elektrooborudovanie-avtomobilya/kompyuternaya-diagnostika-avtomobilya-2824Балаково, Kia Ceed
Добрый день. Соглашусь с Максимом, похоже на блокировку нештатной сигнализации. Таковая установлена в автомобиле? Если нет, то необходимо подключение диагностического оборудования.
Mazda 3
Большое спасибо всем, да стоит каракурт и он помер верней его батарейка
Омск, Hyundai Solaris
Здравствуйте.
Также если на Вашем автомобиле установлена дополнительная охранная система (сигнализация), то причина проблемы может быть в ней. Для начала посмотрите какие лампочки горят на брелке и попробуйте закрыть-открыть автомобиль с сигнализации и после этого завести его ключом. Если это не поможет, то стоит обратиться в центр где была установлена сигнализация. Также начать стоит с компьютерной диагностики.
Россия, Subaru Legacy
org/Answer»>Добрый день! Как заметил Максим если сигнализация с меткой или метка установлена отдельно, то причина может быть в ее батарейки, ее просто стоит заменить. Если сигнализации и меток нет, тогда стоит проверять давление в топливной системе и подключать сканер читать ошибки.
Ростов-на-Дону, Kia Ceed
org/Answer»>ТОП-5 причин почему не заводится Хендай Солярис!
Hyundai Solaris – популярный бюджетный автомобиль, который имеет качественную сборку. Большое количество модификаций сделали автомобиль практичным и востребованным на территории. Но даже надежная машина может в любой момент подвести, она может перестать заводиться. Во время поворота ключа в замке зажигания мотор может прокручиваться, но не срабатывать. Это может быть связано с разными причинами.
Неисправности каталитического нейтрализатора
Многие водители отмечают, что проблема может крыться в неисправном катализаторе, машина прост отказывается заводиться. Одно из самых популярных решений данной проблемы, это удаление каталитического фильтра, и установка пламегасителя вместо неисправного узла.
Связана данная проблема с тем, что фильтр теряет пропускную способность из-за сильного нагрева, которое вызвано пропусками воспламенения.
Основной признак, что проблема в фильтре – двигатель сначала схватывает, но сразу глохнет.
Стартер крутит, но машина не запускается
Бывает стартер прокручивается, но мотор не срабатывает. Чтобы проверить и устранить стоит провести следующие действия:
· Проверяется показатель топливной смеси.
· Диагностируются электроцепи, их исправность, а также проверяется соединение клемм.
· Диагностируются катушки.
· Проверяется состояние свечей.
· Проверяется состояние топливопровода.
· После следует попытаться запустить мотор.
Проблемы со стартером или аккумулятором
Среди частых причин можно выделить проблемы в работе стартера. При работе стартер прокручивается медленно или не запускает мотор. Эти проявления часто наблюдаются у Hyundai Solaris с АКПП.
Решить проблему поможет инструкция – рычаг переводится в положение для переключения передач скорости на нейтралку или тормоз.
Автомобиль может не запускаться из-за низкого заряда или полного разряда аккумуляторной батареи. Чтобы провести проверку можно воспользоваться следующими рекомендациям:
· Для начала проверяется состояние клемм батареи.
· После проводится визуальная проверка проводов, которые идут к стартеру. У них не должно быть разрывов, повреждений, они должны иметь прочное соединение с выводами.
· В салоне можно включить свет, это поможет понять, требуется ли проводить зарядку АКБ. Если будет свет будет тусклым или будет наблюдаться выключение лампочек при попытке запустить мотор, то значит нужно провести зарядку аккумулятора.
· Можно попробовать прикурить машину от другого авто.
Записаться на диагностику можно на сайте Mos Glush.
ru!
Проблемы с иммобилайзером
Иммобилайзер – защитный прибор, который проводит идентификацию владельца и заводит машину, но при условии, если будет наблюдаться достоверное совпадение цифрового кода в чипе ключа со сведениями на устройстве. Бывает, что лампа горит, а иммобилайзер не распознает ключ.
Среди способов устранения проблем можно выделить:
· Можно попытаться 2-3 раза вставить и вынуть ключ из замка зажигания. Это занимает 30 минут, приводит к тому, что машина заводится.
· Можно пробовать открыть доступ к мотору, в этом поможет дубликат ключа или его точная копия. Если двигатель запуститься сразу, то проблема в сломанном ключе.
· Поломка антенны иммобилайзера. До ЭБУ сигнал может не доходить, и в результате ключ будет распознаваться, как подлинный. Чтобы устранить проблему можно попытаться подвигать замок зажигания или использовать жидкость WD-40, при помощи нее можно провести зачистку контактов.
Неисправность свечей зажигания
Часто плохое срабатывание зажигания может быть из-за проблем в функционировании свечей зажигания. Если мотор не срабатывает, то требуется провести их проверку. Для начала проводится снятие крышки из пластика, извлекаются катушки, которые находятся в свечном колодце.
Затем выкручиваются свечи и проводится их проверка:
· Мокрые свечи. Это указывает на то, что топливопровод исправен, достаточно провести замену свечей.
· Сухие свечи. Это может быть признаком того, что бензонасос находится в неисправном состоянии, а также может быть засорен фильтр от топливной системы. Проводится замена фильтра, также требуется проверить состояние фильтрационного устройства от воздушной системы.
Неисправность датчика ДАД и термометра
В машине Hyundai Solaris данные датчики работают вместе.
Иногда достаточно их переставить – это поможет быстро завести двигатель.
Но иногда с датчиком ДАД может случиться поломка, и в этом случае не выйдет запустить машину. К причинам проблем можно отнести:
· Возникновение подсоса воздуха, это может быть из-за появления промежутка между датчиком и штуцером входного вида.
· Появление грязи в области трубопровода.
· Неисправность температурного датчика.
· Наличие повреждений во внутренних проводах или пробоя в полупроводнике.
· Разрыв соединение проводов.
Чтобы выявить проблемы, из-за которых не получается завести автомобиль, можно обратиться в автосервис. В нем будет проведена полная диагностика машины, которая позволит установить главные причины и поломки. А уже после специалисты смогут быстро провести качественный ремонт или полную замену деталей, которые вышли из строя.
solaris — zfs send -i/receive останавливается
При установке Solaris 11.
1 я вижу зависание при получении инкрементного потока zfs. Потоки исходят из установки Solaris 11.0, создаются с помощью zfs send -i и передаются через mbuffer . В какой-то момент времени я могу иногда наблюдать падение производительности записи (практически нет операций чтения или записи на целевых дисках, mpstat сообщает об использовании на одном и том же или разных ядрах, что в сумме составляет чуть более 100% для «системы», с 0 другая нагрузка):
root@receiver:~# mpstat 5 [...] CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 0 363 103 213 0 9 4 0 14 0 6 0 94 1 0 0 0 113 3 149 0 11 6 0 16 0 12 0 88 2 1 0 2 40 4 36 0 9 5 0 3 0 1 0 99 3 0 0 0 82 59 18 0 2 3 0 3 0 93 0 7 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3 0 0 362 104 207 0 96 0 12 0 14 0 86 1 0 0 0 90 4 109 0 10 7 0 3 0 17 0 83 2 0 0 0 48 2 40 0 9 3 0 5 0 10 0 90 3 0 0 0 100 54 44 0 7 3 0 4 0 69 0 31 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 0 332 103 35 0 6 3 0 0 0 45 0 55 1 0 0 0 27 3 22 0 3 1 0 0 0 45 0 55 2 0 0 0 142 3 172 0 96 0 4 0 18 0 82 3 0 0 0 181 56 178 0 10 6 0 8 0 1 0 99 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 0 327 103 54 0 5 2 0 2 0 49 0 51 1 0 0 0 46 3 52 0 9 3 0 0 0 28 0 72 2 0 0 0 156 2 175 0 9 5 0 4 0 25 0 75 3 0 0 0 153 62 132 1 8 6 0 5 0 3 0 97 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 1 380 103 164 0 11 90 7 0 5 0 95 1 0 0 0 144 3 165 0 11 9 0 6 0 25 0 75 2 0 0 0 39 1 36 0 6 4 0 2 0 66 0 34 3 0 0 0 125 77 55 0 10 6 0 1 0 14 0 86 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 0 372 107 178 0 9 9 0 19 0 3 0 97 1 0 0 0 145 3 193 0 9 10 0 8 0 8 0 92 2 0 0 0 24 2 26 0 93 0 0 0 2 0 98 3 0 0 0 94 86 3 0 0 5 0 0 0 100 0 0
После еще 200-300 МБ, записанных пачками, передача почти останавливается:
root@receiver:~# zpool iostat tank 5
полоса пропускания операций с емкостью
пул выделить бесплатно чтение запись чтение запись
---------- ----- ----- ----- ----- ----- -----
бак 1,85 т 2,01 т 511 831 7,76 м 4,60 м
бак 1,85 т 2,01 т 0 26 0 65,4 К
бак 1.
85т 2.01т 3 25 13.2к 62.4к
бак 1.85T 2.01T 4 34 5.00K 76.2K
бак 1.85T 2.01T 3 32 3.10K 87.0K
бак 1,85 т 2,01 т 0 25 1,20 К 59.0К
бак 1.85т 2.01т 6 58 4.30к 339к
бак 1,85 т 2,01 т 1 28 3,70 тыс. 63,1 тыс.
бак 1.85т 2.01т 19 30 36.9к 83.2к
85т 2.01т 3 25 13.2к 62.4к
бак 1.85T 2.01T 4 34 5.00K 76.2K
бак 1.85T 2.01T 3 32 3.10K 87.0K
бак 1,85 т 2,01 т 0 25 1,20 К 59.0К
бак 1.85т 2.01т 6 58 4.30к 339к
бак 1,85 т 2,01 т 1 28 3,70 тыс. 63,1 тыс.
бак 1.85т 2.01т 19 30 36.9к 83.2к
И буферы на принимающей и отправляющей сторонах используются на 100%.
Похоже, это происходит только с большими (> 5G) моментальными снимками, я вижу зависания ближе к концу потока, после того как первые ГБ были успешно переданы за разумное время. Прием потока все еще работает, всего очень медленно — скорость передачи данных ниже 100 КБ/с (от принимающей стороны mbuffer память к незанятым дискам).
Я также попытался убрать mbuffer из уравнения и передать поток zfs send через SSH непосредственно в zfs receive , но, похоже, это не имеет существенного значения. Снимок в конечном итоге передается, но последние 1-2 гигабайта могут занять несколько часов.
Принимающий хост полностью бездействует, в это время никакие сообщения не выводятся на консоль, в журнал сообщений ядра или /var/log/syslog.
Целевой zpool остается пригодным для использования — я все еще могу получить доступ к другим файловым системам, расположенным в том же zpool, в любое время. Кроме того, получение полных, неинкрементных/нерекурсивных потоков zfs размером в сотни ГБ работает без каких-либо ожидаемых проблем на скорости передачи данных.
Известны ли проблемы с версией 11.1, связанные с этой проблемой? Как я могу дополнительно диагностировать, чего ждет получатель, когда он должен записать поток?
Устранение неполадок, связанных с зависанием и зацикливанием процессов
31/11
В этой главе содержится информация и рекомендации по некоторым конкретным процедурам устранения неполадок, связанных с зависанием или зацикливанием процессов.
Могут возникать проблемы, связанные с зависанием или зацикливанием процессов. Зависание может произойти по многим причинам, но часто происходит из-за тупиковой ситуации в коде приложения, коде API или коде библиотеки.
Зависание может быть связано с ошибкой в Java HotSpot VM.
Иногда кажущееся зависание на самом деле оказывается петлей. Например, ошибка в процессе виртуальной машины, из-за которой один или несколько потоков входят в бесконечный цикл, может потреблять все доступные циклы ЦП.
Первым шагом при диагностике зависания является определение того, простаивает ли процесс виртуальной машины или использует все доступные циклы ЦП. Это можно сделать с помощью встроенной утилиты операционной системы (ОС). Если процесс кажется занятым и потребляет все доступные циклы ЦП, вероятно, проблема заключается в зацикливании потока, а не в тупиковой ситуации. В операционной системе Oracle Solaris, например, команда prstat -L -p pid может использоваться для создания отчета о статистике для всех облегченных процессов (LWP) в целевом процессе и, следовательно, для определения потоков, потребляющих много циклов ЦП.
Эта глава состоит из следующих разделов:
Диагностика циклического процесса
Диагностика зависшего процесса
Библиотека потоков Oracle Solaris 8
Диагностика зацикленного процесса
Если процесс виртуальной машины зацикливается, первым делом нужно попытаться получить дамп потока.
Если можно получить дамп потока, часто будет ясно, какой поток зациклен. Если зациклившийся поток можно идентифицировать, то стек трассировки в дампе потока может определить, где (и, возможно, почему) поток зацикливается.
Если доступна консоль приложения (стандартный ввод/вывод), нажмите комбинацию клавиш Control+\ (в Oracle Solaris или Linux) или комбинацию клавиш Control+Break (в Windows), чтобы виртуальная машина HotSpot напечатала дамп потока , включая состояние потока. В операционных системах Oracle Solaris и Linux дамп потока также можно получить, отправив процессу SIGQUIT (команда kill -QUIT pid ). В этом случае дамп потока выводится на стандартный вывод целевого процесса. Вывод может быть направлен в файл, в зависимости от того, как был запущен процесс.
Если процесс Java запущен с параметром командной строки -XX:+PrintClassHistogram , то обработчик Control+Break создаст гистограмму кучи.
Если можно получить дамп потока, то хорошим местом для начала является стеки потоков, которые находятся в состоянии RUNNABLE .
См. Дамп потока для получения дополнительной информации о формате дампа потока, а также таблицы возможных состояний потока в дампе потока. В некоторых случаях может потребоваться получить последовательность дампов потоков, чтобы определить, какие потоки постоянно заняты.
Если консоль приложения недоступна (например, процесс запущен в фоновом режиме или вывод ВМ направлен в неизвестное место), то для получения потока стека можно использовать утилиту jstack . См. Утилита jstack для получения дополнительной информации о выводе этой утилиты. Утилита jstack также должна использоваться, если дамп потока не предоставляет никаких доказательств того, что поток Java зацикливается.
При просмотре вывода jstack , сначала сосредоточьтесь на потоках, которые находятся в состоянии RUNNABLE . Это наиболее вероятное состояние для потоков, которые заняты и, возможно, зациклены. Возможно, потребуется выполнить jstack несколько раз, чтобы лучше понять, какие потоки зацикливаются.
Если поток всегда находится в состоянии RUNNABLE , то можно использовать параметр -m для печати собственных кадров и дополнительной подсказки о том, что делает поток. Если кажется, что поток непрерывно зацикливается, находясь в RUNNABLE , эта ситуация может указывать на потенциальную ошибку виртуальной машины HotSpot, которая требует дальнейшего изучения.
Если виртуальная машина не отвечает на Control+\, это может указывать на ошибку виртуальной машины, а не на проблему с кодом приложения или библиотеки. В этом случае используйте jstack с параметром -m , чтобы получить стек потоков для всех потоков. Выходные данные будут включать стеки потоков для внутренних потоков ВМ. В этой трассировке стека определите потоки, которые, по-видимому, не ожидают. Например, в операционной системе Oracle Solaris вы идентифицируете потоки, которых нет в таких функциях, как 9.0003 __lwp_cond_wait , __lwp_park , ___pollsys или другие блокирующие функции.
Если окажется, что зацикливание вызвано ошибкой виртуальной машины, соберите как можно больше данных и отправьте отчет об ошибке. Дополнительные сведения о сборе данных см. в разделе Отправить отчет об ошибке.
Диагностика зависшего процесса
Используйте дамп потока для диагностики зависшего процесса.
Если кажется, что приложение зависло, а процесс простаивает, то первым делом нужно попытаться получить дамп потока. Если консоль приложения доступна, нажмите Control+\ (в Oracle Solaris или Linux) или Control+Break (в Windows), чтобы виртуальная машина HotSpot напечатала дамп потока. В операционных системах Oracle Solaris и Linux дамп потока также можно получить, отправив SIGQUIT процессу (команда kill -QUIT pid ). Если зависший процесс может сгенерировать дамп потока, то выходные данные выводятся на стандартный вывод целевого процесса.
После печати дампа потока виртуальная машина HotSpot выполняет алгоритм обнаружения взаимоблокировок.
В следующих разделах описаны различные ситуации для зависшего процесса.
Обнаружена взаимоблокировка
Тупик не обнаружен
Нет дампа потока
Обнаружена взаимоблокировка
Если обнаружена взаимоблокировка, она будет напечатана вместе со трассировкой стека потоков, вовлеченных в взаимоблокировку.
В следующем примере показана трассировка стека для этой ситуации.
Найден один тупик на уровне Java:
==============================
«AWT-EventQueue-0»:
ожидание блокировки монитора 0x000ffbf8 (объект 0xf0c30560, java.awt.Component$AWTTreeLock),
который принадлежит «главному»
"главный":
ожидание блокировки монитора 0x000ffe38 (объект 0xf0c41ec8, java.util.Vector),
который удерживается "AWT-EventQueue-0"
Информация о стеке Java для потоков, перечисленных выше:
================================================== знак равно
«AWT-EventQueue-0»:
в java.awt.Container. removeNotify(Container.java:2503)
- ожидание блокировки <0xf0c30560> (java.awt.Component$AWTTreeLock)
в java.awt.Window$1DisposeAction.run(Window.java:604)
в java.awt.Window.doDispose(Window.java:617)
в java.awt.Dialog.doDispose(Dialog.java:625)
в java.awt.Window.dispose(Window.java:574)
в java.awt.Window.disposeImpl(Window.java:584)
в java.awt.Window$1DisposeAction.run(Window.java:598)
- заблокирован <0xf0c41ec8> (java.util.Vector)
в java.awt.Window.doDispose(Window.java:617)
в java.awt.Window.dispose(Window.java:574)
в javax.swing.SwingUtilities$SharedOwnerFrame.dispose(SwingUtilities.java:1743)
в javax.swing.SwingUtilities$SharedOwnerFrame.windowClosed(SwingUtilities.java:1722)
в java.awt.Window.processWindowEvent(Window.java:1173)
в javax.swing.JDialog.processWindowEvent(JDialog.java:407)
в java.awt.Window.processEvent(Window.java:1128)
в java.awt.Component. dispatchEventImpl(Component.java:3922)
в java.awt.Container.dispatchEventImpl(Container.java:2009)
в java.awt.Window.dispatchEventImpl(Window.java:1746)
в java.awt.Component.dispatchEvent(Component.java:3770)
в java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
в java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:214)
в java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
в java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
в java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
в java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
"главный":
в java.awt.Window.getOwnedWindows(Window.java:844)
- ожидание блокировки <0xf0c41ec8> (java.util.Vector)
в javax.swing.SwingUtilities$SharedOwnerFrame.installListeners(SwingUtilities.java:1697)
в javax.swing.SwingUtilities$SharedOwnerFrame.addNotify(SwingUtilities. java:1690)
в java.awt.Dialog.addNotify(Dialog.java:370)
- заблокирован <0xf0c30560> (java.awt.Component$AWTTreeLock)
в java.awt.Dialog.conditionalShow(Dialog.java:441)
- заблокирован <0xf0c30560> (java.awt.Component$AWTTreeLock)
в java.awt.Dialog.show(Dialog.java:499)
в java.awt.Component.show(Component.java:1287)
в java.awt.Component.setVisible(Component.java:1242)
в test01.main(test01.java:10)
Найден 1 тупик.
removeNotify(Container.java:2503)
- ожидание блокировки <0xf0c30560> (java.awt.Component$AWTTreeLock)
в java.awt.Window$1DisposeAction.run(Window.java:604)
в java.awt.Window.doDispose(Window.java:617)
в java.awt.Dialog.doDispose(Dialog.java:625)
в java.awt.Window.dispose(Window.java:574)
в java.awt.Window.disposeImpl(Window.java:584)
в java.awt.Window$1DisposeAction.run(Window.java:598)
- заблокирован <0xf0c41ec8> (java.util.Vector)
в java.awt.Window.doDispose(Window.java:617)
в java.awt.Window.dispose(Window.java:574)
в javax.swing.SwingUtilities$SharedOwnerFrame.dispose(SwingUtilities.java:1743)
в javax.swing.SwingUtilities$SharedOwnerFrame.windowClosed(SwingUtilities.java:1722)
в java.awt.Window.processWindowEvent(Window.java:1173)
в javax.swing.JDialog.processWindowEvent(JDialog.java:407)
в java.awt.Window.processEvent(Window.java:1128)
в java.awt.Component.
dispatchEventImpl(Component.java:3922)
в java.awt.Container.dispatchEventImpl(Container.java:2009)
в java.awt.Window.dispatchEventImpl(Window.java:1746)
в java.awt.Component.dispatchEvent(Component.java:3770)
в java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
в java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:214)
в java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
в java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
в java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
в java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
"главный":
в java.awt.Window.getOwnedWindows(Window.java:844)
- ожидание блокировки <0xf0c41ec8> (java.util.Vector)
в javax.swing.SwingUtilities$SharedOwnerFrame.installListeners(SwingUtilities.java:1697)
в javax.swing.SwingUtilities$SharedOwnerFrame.addNotify(SwingUtilities.
java:1690)
в java.awt.Dialog.addNotify(Dialog.java:370)
- заблокирован <0xf0c30560> (java.awt.Component$AWTTreeLock)
в java.awt.Dialog.conditionalShow(Dialog.java:441)
- заблокирован <0xf0c30560> (java.awt.Component$AWTTreeLock)
в java.awt.Dialog.show(Dialog.java:499)
в java.awt.Component.show(Component.java:1287)
в java.awt.Component.setVisible(Component.java:1242)
в test01.main(test01.java:10)
Найден 1 тупик.
Обнаружение взаимоблокировок по умолчанию работает с блокировками, полученными с помощью ключевого слова synchronized, а также с блокировками, полученными с помощью пакета java.util.concurrent . Если установлен флаг виртуальной машины Java -XX:+PrintConcurrentLocks , трассировка стека также показывает список владельцев блокировок.
Если обнаружена взаимоблокировка, необходимо более подробно изучить выходные данные, чтобы понять причину взаимоблокировки. В предыдущем примере поток main блокирует объект 0xf0c30560 и ожидает ввода 0xf0c41ec8 , который заблокирован потоком AWT-EventQueue-0 .
Однако поток AWT-EventQueue-0 ожидает ввода 0xf0c30560 , который заблокирован main .
Детали трассировки стека предоставляют информацию, которая поможет вам найти взаимоблокировку.
Взаимоблокировка не обнаружена
Если дамп потока распечатывается и взаимоблокировки не обнаружены, проблема может заключаться в ошибке, из-за которой поток ожидает монитор, который никогда не уведомляется. Это может быть проблема синхронизации или общая логическая ошибка.
Чтобы узнать больше о проблеме, проверьте каждый поток в дампе потока и каждый поток, заблокированный в Object.wait() . Фрейм вызывающей стороны в трассировке стека указывает класс и метод, вызывающий метод ожидания() . Если код был скомпилирован с информацией о номере строки (по умолчанию), то это указывает на код, который нужно исследовать. В большинстве случаев для дальнейшей диагностики этой проблемы необходимо иметь некоторое представление о логике приложения или библиотеке.
В общем, вы должны понимать, как работает синхронизация в приложении, а также детали и условия, когда и где уведомляются мониторы.
Нет дампа потока
Если виртуальная машина заблокирована или зависла, используйте 9Команда 0003 jstack .
Если ВМ не отвечает на клавиши Control+\ или Control+Break, возможно, ВМ заблокирована или зависла по какой-то другой причине. В этом случае используйте утилиту jstack для получения дампа потока. Это также применимо в случае, когда приложение недоступно или вывод направлен в неизвестное место.
В выходных данных jstack проверьте каждый из потоков в состоянии BLOCKED . Верхняя рамка может иногда указывать, почему поток заблокирован (например, Object.wait или Thread.sleep ). Остальная часть стека покажет, что делает поток. Это особенно верно, когда исходный код скомпилирован с информацией о номере строки (по умолчанию), и вы можете делать перекрестные ссылки на исходный код.
Если поток находится в состоянии BLOCKED и причина этого не ясна, используйте параметр -m для получения смешанного стека. С выводом смешанного стека должна быть возможность определить, почему поток заблокирован. Если поток заблокирован при попытке войти в синхронизированный метод или блок, то вы увидите такие кадры, как ObjectMonitor::введите в верхней части стека. В следующем примере показан пример выходных данных со смешанным стеком.
------------------ т@13 ------------------ 0xff31e8b8 ___lwp_cond_wait + 0x4 0xfea8c810 void ObjectMonitor::EnterI(Thread*) + 0x2b8 0xfeac86b8 void ObjectMonitor::enter2(Thread*) + 0x250 :
Потоки в состоянии RUNNABLE также могут быть заблокированы. Верхние кадры в смешанном стеке должны указывать, что делает поток.
Один конкретный поток для проверки — ВМТред . Это специальный поток, используемый для выполнения таких операций, как сборка мусора (GC).
Его можно определить как поток, выполняющий VMThread::run() в своих начальных кадрах. В Oracle Solaris это обычно t@4 . В Linux его можно идентифицировать по искаженному имени C++ _ZN8VMThread4loopEv .
Как правило, поток виртуальной машины находится в одном из трех состояний: ожидание выполнения операции с виртуальной машиной, синхронизация всех потоков при подготовке к операции с виртуальной машиной или выполнение операции с виртуальной машиной. Если вы подозреваете, что зависание связано с ошибкой виртуальной машины HotSpot, а не с тупиком приложения или библиотеки классов, обратите особое внимание на поток виртуальной машины.
Если кажется, что поток виртуальной машины застрял в SafepointSynchronize::begin , это может указывать на проблему с переводом виртуальной машины в безопасную точку. Точка сохранения указывает, что все потоки, выполняющиеся в виртуальной машине, заблокированы и ожидают завершения специальной операции, такой как сборка мусора.
Если поток виртуальной машины застрял в функции , где функция заканчивается на doit , это также может указывать на проблему с виртуальной машиной.
В общем, если вы можете запустить приложение из командной строки и вы попадаете в состояние, когда ВМ не отвечает на Control+\ или Control+Break, более вероятно, что вы обнаружили ошибку ВМ, поток проблема с библиотекой или ошибка в другой библиотеке. Когда это произойдет, получите аварийный дамп. См. Сбор основных дампов для получения инструкций о том, как собрать как можно больше информации, а также отправить отчет об ошибке или позвонить в службу поддержки.
Еще один инструмент, который следует упомянуть в контексте зависших процессов, — это утилита pstack в операционной системе Oracle Solaris. В операционных системах Oracle Solaris 8 и 9 эта утилита печатает стеки потоков для LWP в целевом процессе. В операционной системе Oracle Solaris 10 и, начиная с выпуска JDK 5.
0, вывод pstack аналогичен, хотя и не идентичен выводу jstack -m . Как и в случае jstack , реализация операционной системы Oracle Solaris 10 pstack выводит полное имя класса, имя метода и индекс байт-кода (BCI). Он также будет печатать номера строк для случаев, когда исходный код был скомпилирован с информацией о номере строки (по умолчанию). Это полезно для разработчиков и администраторов, знакомых с другими утилитами операционной системы Oracle Solaris, использующими функции файловой системы /proc .
Эквивалентным инструментом pstack в Linux является lsstack . Эта утилита включена в некоторые дистрибутивы и может быть получена из sourceforge. На момент написания статьи lsstack сообщает только о собственных фреймах.
Библиотека потоков Oracle Solaris 8
Библиотека потоков по умолчанию в операционной системе Oracle Solaris 8 часто называется библиотекой T1.
В этой библиотеке потоков реализована модель многопоточности m:n, в которой m пользовательских потоков сопоставляются с n потоками уровня ядра (LWP). Операционная система Oracle Solaris 8 также поставлялась с альтернативной и более новой библиотекой потоков в /usr/lib/lwp . Альтернативную библиотеку потоков часто называют библиотекой T2, и она стала библиотекой потоков по умолчанию в Oracle Solaris 9.и 10 операционных систем. В более старых версиях J2SE (в частности, до 1.4.0) возник ряд проблем с библиотекой потоков по умолчанию (например, ошибки в библиотеке потоков, проблемы синхронизации LWP или нехватка LWP). LWP голодание — это сценарий, в котором есть пользовательские потоки в состоянии RUNNABLE , но нет доступных потоков уровня ядра.
Хотя упомянутые проблемы являются историческими, следует отметить, что когда программное обеспечение JDK развертывается в операционной системе Oracle Solaris 8, оно по-прежнему использует библиотеку T1 по умолчанию.