как вы терпите крах jvm?

<p>я читал книгу о навыках программирования, в которой автор спрашивает интервьюируемого: "как ты разбил jvm?" я думал, что вы можете сделать это, написав бесконечный цикл for, который в конечном итоге израсходует всю память.</p><p>у кого-нибудь есть идеи?</p>

<p>наиболее близким к одному "ответу" является <code>system.exit()</code>, который немедленно завершает работу jvm без надлежащей очистки. но кроме этого, нативный код и исчерпание ресурсов являются наиболее вероятными ответами. в качестве альтернативы вы можете посмотреть на систему отслеживания ошибок sun на предмет ошибок в вашей версии jvm, некоторые из которых допускают повторяющиеся сценарии сбоев. мы привыкли получать полурегулярные сбои при приближении к пределу памяти 4 гб в 32-битных версиях (сейчас мы обычно используем 64-битные).</p>

<p>я бы не назвал сброс outofmemoryerror или stackoverflowerror аварийным завершением. это просто нормальные исключения. для реального сбоя vm есть 3 способа:</p><ol> <li>используйте jni и вылетите в нативный код.</li> <li>если менеджер безопасности не установлен, вы можете использовать отражение для сбоя виртуальной машины. это специфично для vm, но обычно vm сохраняет набор указателей на собственные ресурсы в частных полях (например, указатель на объект собственного потока хранится в длинном поле в - <strong>java.lang.thread</strong>). просто измените их с помощью отражения, и vm рано или поздно вылетит.</li> <li>все виртуальные машины имеют ошибки, поэтому вам просто нужно их вызвать.</li> </ol><p>для последнего метода у меня есть короткий пример, который приводит к аварийному завершению работы горячей точки sun vm спокойно:</p><pre><code>public class crash { public static void main(string[] args) { object[] o = null; while (true) { o = new object[] {o}; } } } </code></pre><p>это приводит к переполнению стека в gc, поэтому вы получите не stackoverflowerror, а настоящий сбой, включая файл hs\_err *.</p>

<p> <a href="http://en.wikipedia.org/wiki/java\_native\_interface">jni</a> . фактически, с jni сбой является режимом работы по умолчанию. вы должны работать очень усердно, чтобы не потерпеть крах.</p>

<p>использовать этот:</p><pre><code>import sun.misc.unsafe; public class crash { private static final unsafe unsafe = unsafe.getunsafe(); public static void crash() { unsafe.putaddress(0, 0); } public static void main(string[] args) { crash(); } } </code></pre><p>этот класс должен находиться в пути загрузки класса, потому что он использует доверенный код, поэтому запустите его так:</p><blockquote> <p>java -xbootclasspath/p :. авария</p> </blockquote>

<p>я пришел сюда, потому что также столкнулся с этим вопросом в <a href="https://rads.stackoverflow.com/amzn/click/com/1934356344">страстный программист</a> чеда фаулера. для тех, у кого нет доступа к копии, вопрос оформлен как своего рода фильтр/тест для кандидатов, проходящих собеседование на должность, требующую "действительно хороших java программистов".</p><p>в частности, он спрашивает:</p><blockquote> <p>как бы вы написали программу на чистом java, которая бы вызывала сбой виртуальной машины java?</p> </blockquote><p>я программировал в java более 15 лет, и я нашел этот вопрос и озадачивающим, и несправедливым. как уже отмечали другие, java, как управляемый язык, специально разработан <em>, чтобы не падать </em>. конечно, всегда есть ошибки jvm, но:</p><ol> <li>после более чем 15 лет jre производственного уровня это случается редко.</li> <li>любые такие ошибки, вероятно, будут исправлены в следующем выпуске, так какова вероятность того, что вы, как программист, столкнетесь и вспомните детали текущего набора jre show-stoppers?</li> </ol><p>как уже упоминали другие, некоторый нативный код через jni - верный способ сбить jre. но автор специально упомянул <em> в чистой java </em>, так что это не так.</p><p>другим вариантом может быть подача фиктивных байтовых кодов jre; достаточно просто скопировать некоторые двоичные данные мусора в файл .class и попросить jre запустить его:</p><pre><code>$ echo 'crap crap crap' > crap.class $ java crap exception in thread "main" java.lang.classformaterror: incompatible magic value 1668440432 in class file crap </code></pre><p>это считается? я имею в виду, что сама jre не разбилась; он правильно обнаружил поддельный код, сообщил об этом и вышел.</p><p>это оставляет нам наиболее очевидные виды решений, такие как очистка стека с помощью рекурсии, исчерпание памяти кучи с помощью выделения объектов или просто выброс <code>runtimeexception</code>. но это просто приводит к выходу jre с <code>stackoverflowerror</code> или аналогичным исключением, что опять-таки <em> на самом деле не является крахом </em>.</p><p>так что осталось? мне бы очень хотелось услышать, что автор действительно имел в виду как правильное решение.</p><p><strong> обновление </strong>: чад фаулер <a href="https://twitter.com/chadfowler/status/227845163031072768">ответил здесь</a> .</p><p>ps: это отличная книга. я взял это для моральной поддержки, изучая руби.</p>

<p>этот код приведет к аварийному завершению работы jvm</p><pre><code>import sun.dc.pr.pathdasher; public class crash { public static void main(string[] args) { pathdasher dasher = new pathdasher(null) ; } } </code></pre>

<p>в прошлый раз, когда я пытался это сделать это:</p><pre><code>public class recur { public static void main(string[] argv) { try { recur(); } catch (error e) { system.out.println(e.tostring()); } system.out.println("ended normally"); } static void recur() { object[] o = null; try { while(true) { object[] newo = new object[1]; newo[0] = o; o = newo; } } finally { recur(); } } } </code></pre><p>первая часть сгенерированного файла журнала:</p><pre><code># # an unexpected error has been detected by java runtime environment: # # exception\_stack\_overflow (0xc00000fd) at pc=0x000000006dad5c3d, pid=6752, tid=1996 # # java vm: java hotspot(tm) 64-bit server vm (11.2-b01 mixed mode windows-amd64) # problematic frame: # v [jvm.dll+0x2e5c3d] # # if you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- t h r e a d --------------- current thread (0x00000000014c6000): vmthread [stack: 0x0000000049810000,0x0000000049910000] [id=1996] siginfo: exceptioncode=0xc00000fd, exceptioninformation=0x0000000000000001 0x0000000049813fe8 registers: eax=0x000000006dc83090, ebx=0x000000003680f400, ecx=0x0000000005d40ce8, edx=0x000000003680f400 esp=0x0000000049813ff0, ebp=0x00000000013f2df0, esi=0x00000000013f0e40, edi=0x000000003680f400 eip=0x000000006dad5c3d, eflags=0x0000000000010206 </code></pre>

<p>идеальная реализация jvm никогда не потерпит крах.</p><p>для сбоя jvm, кроме jni, вам нужно найти ошибку в самом vm. бесконечный цикл просто потребляет процессор. бесконечное распределение памяти должно просто вызывать outofmemoryerror в хорошо построенной jvm. это может вызвать проблемы для других потоков, но хорошая jvm по-прежнему не должна аварийно завершать работу.</p><p>если вы можете найти ошибку в исходном коде виртуальной машины и, например, вызвать ошибку сегментации при использовании памяти реализацией виртуальной машины, то вы действительно можете ее аварийно завершить.</p>

<p>если вы хотите завершить работу jvm - используйте следующее в sun jdk 1.6\_23 или ниже:</p><pre><code>double.parsedouble("2.2250738585072012e-308"); </code></pre><p>это связано с <a href="http://www.theregister.co.uk/2011/02/07/java\_denial\_of\_service\_bug/">ошибка</a> в sun jdk - также найден в openjdk. это исправлено в oracle jdk 1.6\_24 и далее.</p>

<p>зависит от того, что вы подразумеваете под крахом.</p><p>вы можете выполнить бесконечную рекурсию, чтобы она исчерпала пространство стека, но это завершится "изящно". вы получите исключение, но сама jvm будет обрабатывать все.</p><p>вы также можете использовать jni для вызова нативного кода. если вы не сделаете это просто правильно, то вы можете заставить его сильно разбиться. отладка этих сбоев - это "весело" (поверьте мне, мне пришлось написать большой c++ dll, который мы вызываем из подписанного апплета java). :)</p>

<p>книга <a href="http://www.amazon.co.uk/java-virtual-machine-series/dp/1565921941">java virtual machine</a> джона мейера содержит пример серии инструкций байт-кода, которые привели jvm к дампу ядра. я не могу найти свою копию этой книги. если у кого-то есть такой, пожалуйста, посмотрите его и опубликуйте ответ.</p>

<p>сломанное оборудование может привести к сбою любой программы. однажды я воспроизводил аварийное завершение работы приложения на определенной машине, в то время как на других машинах он работал точно с такой же настройкой. оказывается, у машины был неисправный озу.</p>

<p>не сбой, но ближе к падению, чем принятый ответ с использованием <code>system.exit</code></p><p>вы можете остановить jvm, позвонив</p><p><code>runtime.getruntime().halt( status )</code></p><p>согласно документам:</p><blockquote> <p>msgstr "этот метод не приводит к запуску перехватчиков завершения работы и не запускает непроверенные финализаторы, если включена финализация при выходе".</p> </blockquote>

<p>кратчайший путь :)</p><pre><code>public class crash { public static void main(string[] args) { main(args); } } </code></pre>

<p>на winxpsp2 с wmp10 jre6.0\_7</p><p>desktop.open (uritoaviormpgfile)</p><p>это приводит к тому, что порожденная нить выбрасывает неперехваченный throwable и вылетает из точки доступа</p><p>ymmv</p>

<p>если вы определяете сбой как прерывание процесса из-за необработанной ситуации (т. е. нет java исключения или ошибки), то это невозможно сделать из java (если у вас нет разрешения на используйте класс sun.misc.unsafe). в этом весь смысл управляемого кода.</p><p>типичные сбои в нативном коде происходят из-за разыменования указателей на неправильные области памяти (нулевой адрес или неправильное выравнивание). другим источником могут быть недопустимые машинные инструкции (коды операций) или необработанные сигналы от вызовов библиотеки или ядра. оба могут быть запущены, если в jvm или в системных библиотеках есть ошибки.</p><p>например, jit-код (сгенерированный), нативные методы или системные вызовы (графический драйвер) могут иметь проблемы, приводящие к реальным сбоям (было довольно часто случаться сбой, когда вы использовали функции zip и у них не хватало памяти). в этих случаях обработчик сбоя jvm запускает и выводит состояние. он также может генерировать файл ядра ос (dr. watson в windows и дамп ядра в * nix).</p><p>в linux/unix вы можете легко вызвать сбой jvm, отправив ему сигнал запущенному процессу. примечание: вы не должны использовать <code>sigsegv</code> для этого, так как hotspot ловит этот сигнал и повторно генерирует его как исключение nullpointerexception в большинстве мест. так что лучше отправить <code>sigbus</code> например.</p>

<p>вот подробное объяснение причин, по которым jvm вызывает дамп ядра (например, сбой): <a href="http://kb.adobe.com/selfservice/viewcontent.do?externalid=tn\_17534">http://kb.adobe.com/selfservice/viewcontent.do?externalid=tn\_17534</a> </p>

<p>если вы хотите притвориться, что у вас недостаточно памяти, вы можете сделать</p><pre><code>public static void main(string[] args) { throw new outofmemoryerror(); } </code></pre><p>я знаю несколько способов заставить jvm создавать дамп файла ошибок, вызывая нативные методы (встроенные), но лучше всего вы не знаете, как это сделать. ;)</p>

<p>jni является крупным источником сбоев. вы также можете аварийно завершить работу, используя интерфейс jvmti, поскольку он также должен быть написан на c/c++.</p>

<p>если вы создадите процесс потока, который бесконечно порождает больше потоков (которые порождают больше потоков, что ...), вы в конечном итоге вызовете ошибку переполнения стека в самой jvm.</p><pre><code>public class crash { public static void main(string[] args) { runnable[] arr = new runnable[1]; arr[0] = () -> { while (true) { new thread(arr[0]).start(); } }; arr[0].run(); } } </code></pre><p>это дало мне выходной сигнал (через 5 минут следи за своим бараном)</p><pre><code>an unrecoverable stack overflow has occurred. # # a fatal error has been detected by the java runtime environment: # # exception\_stack\_overflow (0xc00000fd) at pc=0x0000000070e53ed7, pid=12840, tid=0x0000000000101078 # # jre version: java(tm) se runtime environment (8.0\_144-b01) (build 1.8.0\_144-b01) # java vm: java hotspot(tm) 64-bit server vm (25.144-b01 mixed mode windows-amd64 compressed oops) # problematic frame: # </code></pre>

<p>кратчайший? используйте класс роботов, чтобы вызвать ctrl + break. я заметил это, когда пытался закрыть свою программу, не закрывая консоль (у нее не было функции выхода).</p>

<p>я делаю это сейчас, но не совсем уверен, как ... :-) jvm (и мое приложение) иногда просто полностью исчезают. нет ошибок, ничего не регистрируется. переходит от работы к тому, чтобы вообще не бегать без предупреждения.</p>

<p>это считается?</p><pre><code>long pid = processhandle.current().pid(); try { runtime.getruntime().exec("kill -9 "+pid); } catch (exception e) {} </code></pre><p>это работает только для linux и из java 9.</p><p>по какой-то причине я не понимаю, <code>processhandle.current().destroyforcibly();</code> не убивает jvm и выдает <code>java.lang.illegalstateexception</code> с сообщением <em>уничтожение текущего процесса не разрешено</em>.</p>