Pull to refresh

Comments 132

Он искал готовых специалистов. Глупость. Искать надо людей, у которых был опыт вникания в работу систем. Таких легко можно адаптировать под тот зоопарк, который есть в компании. Искать спеца под зоопарк — нелепо.
Вы уверены, что человек, который X лет работал с Java и до сих пор даже не удосужился «вникнуть в работу» JVM сможет «вникнуть в работу» каких-либо других систем?

Он ведь не спрашивал про свой зоопарк, он спрашивал про работу системы, с которой человек, предположительно, общается очень и очень много и в которой, предположительно, он чувствует себя очень и очень уверенно!
Java более всего ассоциируется с махровым энтерпрайзом. Почему программист, который работает в энтерпрайз компании должен вникать в то, как устроен его инструментарий? Ещё раз: почему энтерпрайз специалист должен вникать в устройство используемых инструментов?

Если из этого предложения убрать слово «энтерпрайз», вопрос станет уместным. Для энтерпрайза он не уместен — есть вендоры, есть best practice, которым надо следовать. Есть планирование и задачи. Если человек много писал энтерпрайз кода, то он выполнял свои служебные обязанности, а ронять ява-машину в служебные обязанности у него явно не входило.

Искать «хаккеров для явы» — это оксюморон какой-то.
Java более всего ассоциируется с махровым энтерпрайзом. Почему программист, который работает в энтерпрайз компании должен вникать в то, как устроен его инструментарий? Ещё раз: почему энтерпрайз специалист должен вникать в устройство используемых инструментов?
Он никому ничего не должен. Пока он не пытается стоить из себя эксперта.

Давайте сравним с токарем. Если у вас токарь работал «в махровом энтерпрайзе» (== огромной компании) и 10 лет точил себе простенькие гаечки на токарном станке, то это не значит, что он может делать вид, что он — токарь 6го разряда и претендовать на соответствующую должность — для этого он как раз должен уметь выполнять работы, требующие «комбинированного крепления и высокоточной выверки в различных плоскостях». Почему «Java-специалист 6го разряда» (ну хорошо, пусть 5го — он всё-таки себе 9 из 10 приписал, не 10) ничерта не знает про хитрости работы с его инструментом?

Для энтерпрайза он не уместен — есть вендоры, есть best practice, которым надо следовать. Есть планирование и задачи. Если человек много писал энтерпрайз кода, то он выполнял свои служебные обязанности, а ронять ява-машину в служебные обязанности у него явно не входило.
Совершенно верно: он Java-программист 2го (ну хорошо, может быть 3его) разряда. Пусть и с 10 годами работы. Какого фига он корчит из себя что-то большее?

Искать «хаккеров для явы» — это оксюморон какой-то.
Вау. То есть программисты на Java уже не должны никогда писать задачи, где ресурсы имеют цену? С чего вдруг?
Нет уж, если мы говорим про слесарей, давайте переводить на этот же язык.

Слесарь 6ого разряда, говорите? А знаете ли вы как вызвать разрушительный резонанс на вашем станке? То есть вообще не знаете и не думали об этом? Да что вы за слесарь такой? Не 6 разряд, точно.

Почему человек, пищущий код на java и знающий стандартную библиотеку насквозь, да ещё хорошо знающий все общеупотребимые нестандартные, почему он должен хоть в зуб ногой по поводу jvm?

Слесарь 6ого разряда, говорите? А знаете ли вы как вызвать разрушительный резонанс на вашем станке? То есть вообще не знаете и не думали об этом? Да что вы за слесарь такой? Не 6 разряд, точно.
Спасибо за понимание. Я не понимаю как у вас токарь превратился слесаря, но суть дела вы передали весьма точно. Да, если токарь не может объяснить как вызвать разрушительный резонанс (или, что практически важнее, не допустить, чтобы оный резонанс возник), то это не 6й разряд уж точно. Я понимаю, что Java-программисту убить JVM несколько сложнее, чем токарю угробить свой станок, но принцип, в общем-то, тот же.

Почему человек, пищущий код на java и знающий стандартную библиотеку насквозь, да ещё хорошо знающий все общеупотребимые нестандартные, почему он должен хоть в зуб ногой по поводу jvm?
#@$^%#&^@! Ну вы же, чёрт побери, сами всё прекрасно объяснили: не почему, а для чего — для того, чтобы претендовать на звание специалиста высокого класса, эксперта. Он может прекрасно продолжать работать в своём «энтерпрайзе» и следовать «best practice» (даже не пытаясь понять почему они «best» и когда они перестают быть «best»). Но зачем же приписывать себе квалификацию и заявлять что ты владеешь тем, чем ты не владеешь?
UFO just landed and posted this here
Очень точно отражает действительность.
Остается еще добавить завышенную самооценку, и будет полный комплект.
:-)
Вы пытаетесь судить что нужно компании о которой ничего не знаете. Вполне вероятно что им нужен именно Java эксперт, а не JEE эксперт. В энтерпрайз проектах тоже бывают «сложные» места, на которые нужен опытный человек, который мог бы такое место грамотно разработать и огородить его от возможных поломок кривыми руками других девелоперов.

Кстати до прочтения статьи считал себя Java экспертом :)
есть best practice, которым надо следовать

А почему? Почему им надо следовать? Потому что Вася Пупкин так сказал?
Потому что последовательное следования практикам, изложенным в материалах вендора/книжке именитого автора экономит время ваше и тех кто через 5 лет после вас будет переделывать/поддерживать вашу систему при сохранении годного результата.
Т.е. это как следовать руководству по эксплуатации технически сложного прибора, например.
Через пять лет могут оказаться популярными другие вендоры/авторы.
Большинство подходов устаревают.
Более того, те же авторы через 5-10 лет говорят уже другие вещи, иногда прямо противоположные.
Надеюсь, примеров не нужно? :-)
Потому что это энтерпрайз. Человек, который следует best practice всё делает правильно. Даже если получается ужасный монстр или ничего не получается, потому что бюрократия, размывание ответственности и прочие прелести крупных контор просто требуют следовать best practice и не выделываться. А те, кто выделываются — быстро вылетают (если не оказываются сверху).
Wiki в помощь — Best coding practices are a set of informal rules that the software development community has learned over time which can help improve the quality of software.
Many computer programs remain in use for far longer than the original authors ever envisaged (sometimes 40 years or more), so any rules need to facilitate both initial development and subsequent maintenance and enhancement by people other than the original authors.
UFO just landed and posted this here
Например, можно поиграться с Unsafe и попереписывать участки памяти, занятые JVM.
А если попробовать просто вылезти за memory limit? И вообще, а если без unsafe или jni? С unsafe любой дурак может ногу прострелить себе.
Без unsafe и jni — только воспроизвести какую-либо ошибку (как сделал sdevelopment ниже). Спецификация JVM не предусматривает ситуаций, когда машина целиком может упасть (максимум — OutofMemeory или другая RuntimeException). Если упала — значит, ошибка.
Сам не являюсь специалистом в Java (и автором этой книги тоже), поэтому поискал что пишут по этому поводу на stackoverflow:

public class Recur {
public static void main(String[] argv) {
    recur();
}
static void recur() {
    Object[] o = null;
    try {
        while(true) {
            Object[] newO = new Object[1];
            newO[0] = o;
            o = newO;
        }
    }
    finally {
        recur();
    }
}
}


C:\JavaTools>java Recur
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x000000006dad5c3d, pid=6816, tid
=5432
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode windows-amd64)

# Problematic frame:
# V  [jvm.dll+0x2e5c3d]
#
# An error report file with more information is saved as:
# C:\JavaTools\hs_err_pid6816.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#


источник, ещё один вопрос на stackoverflow с примерами.
На stackoverflow посоветовали добиться EXCEPTION_STACK_OVERFLOW… прям тавтология
Слишком долго: обработка исключений занимает намного больше времени, чем просто вызов метода и возврат из него (по крайней мере в Java 1.6).
А, нет, посмотрел — выше именно его и добились, правда, сильно изощрённым способом…
Похоже, для этого требуется намного меньшая вложенность, чем просто для StackOverflowError…
UFO just landed and posted this here
>оценить себя по шкале от 1 до 10. Он сказал девять.
а что вы ожидаете он ответит? «Я пишел устраиваться на разработчика, оцениваю себя на 5-6»?
«Я пришел устраиваться на эксперта» вообще-то. Умение реалистично оценивать свои навыки, и их границы — это даже не про эксперта, это просто про хорошего специалиста.
Ну не знаю, когда я спрашиваю кого-то на сколько баллов он оценивает свое знание С++ и если он отвечает «на 5+», то это очень серьезный повод усомниться. Себе я больше тройки не дам точно (да и специалистом себя назвать не смогу), хотя вроде как больше 10 лет работаю с этим языком. Но чем больше работаешь, тем больше понимаешь, что ничего не понимаешь. Ну или точнее, что существует огромный пласт информации помимо того «базового набора», с которым знакомишься в первый год.

Здесь я думаю та же история. Если человек способен хотя бы обозначить эти сомнения, это уже показатель того что он заглянул дальше азов.
когда я спрашиваю кого-то на сколько баллов он оценивает свое знание С++ и если он отвечает «на 5+», то это очень серьезный повод усомниться
По деситябальной системе?
Нет, по обычной
OK. Но все равно вопрос сложый, как же оценивать знание C++.

Обычно есть некоторый упрощенный повседневный диалект, который отличается от проекта к проекту. Можно успешно писать на плюсах много лет, и даже не знать о продвинутой шаблонной магии. А еще иногда приходится заглядывать в спецификацию языка.
Как говорил тов. Филатов, преподавая в Одессе:
«На 5 медицину знает только сам Господь Бог. На 4 — может быть знаю я. Так что никто из вас, студентов, выше 3 не получит».
Г-дь Б-г тут может быть зменён на Страуструпа… хотя и в нём я не уверен…
Спасибо, я теперь знаю как отвечать на собеседовании, когжа меня попросят оценить свои знания чего-то :)
Страуструп оценивает свои знания С++ на 8 или меньше.
По пятибальной шкале? ;-)
Скажите, на сколько Вы знаете проект, который сейчас разрабатываете? :-)
Вряд ли кто-либо знает больше, чем на 8 из 10.
Так же и Страуструп :-)
Ну все нормально. Начинаешь с 5+, и так дальше, 5, потом 4+. Вот вы уже до троечки прокачались ;)
UFO just landed and posted this here
Да, я тоже списываю подобные ответы на этот эффект. HR же вообще любые осторожные комментарии относительно предметной области склонны рассматривать как признак некомпетентности.
Давно сказано: «Я знаю, что ничего не знаю.»

А ещё пример с окружностью. Чем больше наши знания (круг), тем больше мы соприкасаемся с неизвестным (длина окружности).
По идее, после такого вопроса «как вы себя оцениваете по n-шкале» должно идти разъяснение, что для вас значит максимальная и минимальная оценка. Иначе это просто демагогия, ибо разные системы оценки и понимания шкалы.
Большой плюс.
Еще бы все HR это понимали. :-)
Я лично вследствие вышесказанного избегаю давать численные оценки на собеседовании, ибо они могут сказать только об отношении человека к предмету, да и то косвенно. Вместо этого лучше обрисовать, какие области Вам известны, какие сейчас изучаете, какие в планах.
А где остальные главы? И где происходит перевод?
Перевод происходит силами добровольцев у которых есть доступ к оригиналу, желание и возможность переводить, планирую скоординировать усилия с авторами предыдущих и будущих переводов чтобы не переводить те же главы несколько раз и ускорить процесс. Когда появится возможность добавлю ссылку на предыдущую переведенную главу (статья в данный момент в черновиках), и как только появится следующий перевод — добавлю ссылку на него, для удобства чтения и соблюдения единообразие со стилем оформления первых глав. На данный момент есть переводы первых восьми глав:
Первые 3 главы (автор перевода)
Вступительное слово
Благодарности
Введение
Глава 1. Веди или умри
Глава 2. Спрос и предложение
Глава 3. Кодинг ещё не всё
Главы 4-6 (автор перевода)
Глава 4. Будь худшим
Глава 5. Инвестируйте в свой интеллект
Глава 6. Не слушай своих родителей
Как я отказался от $300.000, предложенных мне компанией Microsoft, взамен на полный рабочий день на GitHub’е
Глава 7 (автор перевода)
На данный момент в черновиках (копия из кэша)
Прошу раскрыть упомянутый у вас простой вопрос о том «как бы Вы написали программу, которая бы никогда не приводила к сбоям JVM», очень интересно.
Вы ответили как уронить, это я и сам могу: нитки, не хвостовая рекурсия, память и тд. А вот как чтобы никогда не приводила к сбоям — это другой, намного более интересный вопрос.
это же очевидно. лучший код — не написанный код, он точно ничего не уронит
Те, кто поддерживает чужой код, пожалуй, согласятся с вами в том, что лучший код — это ненаписанный код…
Это в пределе. :-)
А вообще размер — нехороший показатель.
Короткий код часто оказывается неподдерживаемым.
Короткий код не так жалко выкинуть и переписать для новых условий «по мотивам старого». А длинный действительно приходится поддерживать, и это может оказаться сложнее.
… а у врача можно спросить, как остановить сердце, не прикасаясь к пациенту. Если не умеет — это плохой врач!
Я конечно не врач, но по-моему есть куча способов остановить сердце, не прикасаясь к пациенту. Ведь любого рода смерть включает в себя остановку сердца (было это причиной смерти или следствием в данном случае не важно, задача — остановить сердце). И тут вам и отравляющие газы, и смертельная доза облучения, и шаговый удар током, и смерть от истощения/обезвоживания, и принуждение к самоубийству (так, хабр за это не забанят же?), скажем, с угрозой оружием. Использование третьих лиц для «прикосновений» к пациенту, опять же.

А если придираться к постановке задачи, то можно подумать, что сердце нужно остановить самому себе, тут все еще проще! Но это уже неспортивные придирки, не спорю.
Смысл аналогии в том, что врач не обязан знать как, его работа знать почему — фибриляция, тромб, спазм миокарда и пр. Так и программист должен уметь увидеть по коду и признакам неверный JNI вызов, OOM, нарушение целостности стека и пр. Но уж никак не быть профи в намеренном создании этих ситуаций, если только он не мастер эксплоитов или энтузиаст-тесткр ВМ на прчность.
фибриляция, тромб, спазм миокарда


Это не _почему_, это — результат. Почему — это посмотреть чем пациент занимался последние годы, вломиться к нему домой, и выяснить что могло привести к вышеописанному результату.

Хауз, не цепляйтесь к словам :) к OOM тоже может приводить не явная ошибка, а что-то, требующее изучения всего кода и времени жизни каждого объекта.
к OOM тоже может приводить не явная ошибка, а что-то, требующее изучения всего кода и времени жизни каждого объекта.

«В ДНК у него ошибка...» И вообще, причина — в законах квантовой физики и общей теории относительности, кто их только придумал…
Самые большие проблемы в жизни вовсе не в теории относительности.
И уж тем более не в квантовой физике.
:-)
Наиболее интересна с этой точки зрения психология, но там пока все неоднозначно и расплывчато, мало конкретных ответов, которые можно брать и использовать.
И жизнь, и психология — результат действия законов КФ и ОТО. Или более глубоких ещё не открытых законов. Так что проблемы могут быть не в этих областях, но их причина — наверняка где-то там. Или, как вариант, в неправильном использовании квантовой физики для реализации жизни, а жизни — для реализации психологии…
Да почему же… знание кишков используемой архитектуры дает понимание КАК оно работает, и ПОЧЕМУ может быть первое второе десятое двадцатое…
Такой подход к собеседованиям напоминает подход из анегдота про милицию. Берут либо сильных либо умных. Мне кажется он найдет или специалиста или человека у которого всегда падает джава машина.
Ну почему же. Выше пара человек сходу привели идеи как это сделать. Тут ведь вопрос не в том, чтобы найти человека способного уронить Java-машину, а в том, чтобы найти специалиста достаточно высокого класса, способного хотя бы понимать, что за всеми этими слоями абстрации стоит железяка с её ноликами и единичками, что полностью от этого абстрагироваться нельзя и что как ни крути — это всё равно иногда вылазит в программы с любым количеством абстракций. К сожалению офигительное количество Java-программистов об этом даже не задумывается. Называть таких людей «экспертами» никак нельзя, разумеется, но у них часто бывает много лет работы и они регулярно впустую тратят время всех: и рекрутеров, и тех кто их интервьюирует и своё собственное.
Ну смотрите. Я например слышал что все x86 машины давно уже суперскалярные. Весь x86 код транслируется в совсем другие инструкции и выполняется совсем по другому. Все оптимизация что мы делаем на асемблере, актуальны для x86, но не актуальны под реальные процессоры. И я даже слышал что процессор может переименовывать регистры. И что процессор это виртуальная машина, которая имеет внутри микропрограмму и ее можно апгрейдить. Но я не могу уронить процессор, не могу!

Я даже не интересовался как это сделать. Я пишу на шарпе и приблизительно знаю как работает GC основаный на поколениях. И я не буду никогда оптимизировать свой код для GC. Это проблема создателей GC. Я пишу для тех кто будет мой код поддерживать.
Все оптимизация что мы делаем на асемблере, актуальны для x86, но не актуальны под реальные процессоры.
Вот прям-таки все? А как тогда, собственно, кодеки люди руками на ассемблере пишут?

Но я не могу уронить процессор, не могу!
Вот прям-таки и не можете? Совсем никогда и никакой? И даже статью из Wikipedia никогда не читали?

Да, процессор, вообще говоря, должно быть невозможно уронить. Но, в общем-то, это не так и сложно сделать из ядра OS. Или если в процессоре есть ошибка. Или если вы ему скормите неправильный микрокод (последнее, впрочем, не так просто сделать, так как он в последний версиях CPU подписан). Всё, собственно, как с Java или C#, почти один-в-один (только фатальных ошибок в процессорах поменьше, так как машинка-то в них попроще, а тестируют её гораздо тщательнее).

Я пишу на шарпе и приблизительно знаю как работает GC основаный на поколениях. И я не буду никогда оптимизировать свой код для GC. Это проблема создателей GC.
Вот нифига ж себе. Как вы это себе представляете? У вас программа тормозит и жрёт память, как не в себя, заказчик «рвёт и мечет», а вы ему так с вызовом так говорите «это проблема создателей GC»? Будете оптимизировать как миленький. Ну то есть если вы эксперт и задача действительно в GC упёрлась. Ну а если вы не эксперт — то с какого перепугу на подобное место претендуете?
Вот нифига ж себе. Как вы это себе представляете? У вас программа тормозит и жрёт память, как не в себя, заказчик «рвёт и мечет», а вы ему так с вызовом так говорите «это проблема создателей GC»? Будете оптимизировать как миленький.

Не буду, это ошибка проектирования а не оптимизации. Необходимо перепроектирование системы.
Один раз в моей практике из-за ошибки в одной строке кода производительность просела более чем в 10 раз.
Правильно ли я понимаю, что надо было запрашивать покупку новых серверов и ресурсов для проведения полного перепроектирования системы? Или все-же можно было ограничиться заменой неправильной строки кода на правильную?
Это больше говорит о проектах, в которых вы заняты, чем о том, что знать как устроен GC не нужно.

Разработчики stackowerflow (думаю, вам как шарперу, такой пример ближе), например, на конференциях рассказывают, что с ростом посещаемости были сильно поражены тому, как сильно удалось расширяться не за счет введения в строй новых серверов, а за счет переписывания кода с учетом работы GC.

Разработчики twitter — аналогично, можно найти много их выступлений о тюнинге JVM.

Про Дойчебанк тоже есть информация, что они обучают своих разработчиков занятых на low latency системах как писать код, чтобы минимизировать использование GC
на конференциях рассказывают, что с ростом посещаемости были сильно поражены тому, как сильно удалось расширяться не за счет введения в строй новых серверов, а за счет переписывания кода с учетом работы GC.

Это самая большая ошибка программирования. Написание кода не для людей а для машин. Поэтому мы до сих пор все всегда пишем с нуля, потому что существующий код неозможно поддерживать или портировать.
Страутруп писал вроде, что инструменты заставляют нас писать код под эти инструменты. Самый простой пример это прекомпилед хедерс. Только подумайте, мы меняем код только для того чтобы он быстрее собирался! В глобальном смысле это и ведет к тому хаусу что мы сейчас имеем в программировании.
Это самая большая ошибка программирования. Написание кода не для людей а для машин.
Это было актуально лет 40 назад. В узких областях актуально и сейчас. В биржевой торговле время машины до сих пор время машины стоит много больше времени программиста: лишняя миллисекунда — и конкуренты опередили.
В биржевой торговле рулят алгоритмы (быстрые) а не оптимизации под железо. Пересекались, знаем.
Трейдеры с Вами немного не согласны: habrahabr.ru/post/163371/
Иногда, они и свое железо под задачу пилят, а не только софт под железо.
В возражаемом вами комментарии говорилось об оптимизации под GC, а не под железо…
GC это домен для шарпа как и процессор для байткода.
Не писал для CLI, может быть, GC для CLI меньше допускает оптимизацию кода под него, чем GC для JVM…
Друзья, зачет минусуете? (смайлик) Вы же помните о чем написано в книгах о паттернах. В них почти все паттерны для управления сложностью кодом и упрощение модификации и поддержки — это все для людей а не для машин! Нас учат писать код для людей!
Это не отменяет следования best practices, которые ориентированы на различные аспекты: уменьшение вероятности непреднамеренной ошибки, повышение понятности для человека, «правильная» работа с абстракциями (в том числе, в тех местах, где они протекают).
Однажды столкнулся похожим на собеседовании. Вопрос был оцените по 5-и бальной шкале свое знание JavaScript (хотя вакансия вообще была не связана с этим). Я написал 4 без особых колебаний (до этого я прочитал книгу и сделал пару учебных скриптов для собственного развития), но решил, что вобщем-то всё равно для этой вакансии. На что собеседователь (видимо «По моим ожиданиям он должен быть невероятным специалистом») очень обрадовался и начал задавать заковыристые вопросы по неявному преобразованию типов и каких-то особенностях DOM, на которые я конечно не смог правильно ответить. И в конце он так торжественно так спросил, почему же я поставил себе 4? Я ответил, что это субъективная оценка и 4 значит, что я уверен, что спокойно смогу решать задачи и на JavaScript
Коммуникация помогает преодолевать барьеры различного трактования одних и тех же символов.
Лично я как разработчик еще пять лет назад сделал неутешительный для себя вывод, что большинство проблем адекватнее решать на уровне коммуникации, а не на техническом уровне.
На техническом уровне уже нет пространства маневра, и приходится делать хаки.
В Enterprise-разработке самая большая проблема — постановка задачи.
И попытка решать эту задачу путем технической гибкости — IMHO, слишком большая цена.
Я устроился на первую работу ровно 3 дня назад. Эти три дня я официально называю себя Java-разработчиком. Я долго шел к этому. Заканчивал химический факультет.
Те вопросы, что упоминаются в статье(положить JVM, работа загрузчиков классов и т.д.) с легкостью ответил бы. Сейчас, вчера и завтра. Но вчера, когда ресурс_менеджер услышал, что я хочу не 600 долларов, а 1000 — ответил, что ему нужно с кем-то бесседовать и нет никаких гарантий, что я подойду им по бюджету. Компания очень крупная.

Повторяю, это моя первая работа в IT. И у меня нет опыта разработки. Но судя по вашей статье — я эксперт!
например StackOverflow'ом. Даже пустой метод в джаве занимает память. Просто объявите метод и вызывайте его рекурсивно. Машина вскоре ляжет. А для быстроты, уменьшите размер стека при запуске JVM до минимального значения — и получите результат очень быстро.
Или OutOfMempryError: Для простоты эксперимента уменьшите heap JVM специальтым ключом и попробуйте поработать с большими объектами. К примеру Bitmap'ами
Одним словом, любая Error из дерева иерархии ошибок, выброшенная не вручную, а самой машиной — это конец JVM
Error — это не падение JVM. Часть приложений, в особенности запускающих недоверенный код, перехватывают Error (обычно просто все Throwable) и иногда принимают какие-то попытки восстановления.

Сходу в голову приходят сервлет-контейнеры, апплет-контейнеры, IDE/отладчики, различные механизмы модульности (при невозможности загрузить модуль). После части ошибок возможно восстановиться и продолжить работу. Например, после OOM в пользовательском приложении контейнер может его завершить и выгрузить. Или после неудачной попытки загрузки класса (не важно, ValidationError случился или какой-нибудь NoClassDefFoundError).

Уронить JVM означает, что JVM не может продолжать работу (это могут быть, например, проблемы загрузки классов System ClassLoader'ом, OOM по PermGen, проблемы в JNI, неудачная работа с sun.misc.Unsafe).

Из недавнего: в драйвере MongoDB (я наблюдал проблему с 2.7.2, исправлена в 2.9.0) можно получить забавный java.lang.Error: Maximum permit count exceeded, связанный с неправильной работой с семафорами и переполнением int. См. тикет.
log
Caused by: java.lang.Error: Maximum permit count exceeded
        at java.util.concurrent.Semaphore$Sync.tryReleaseShared(Semaphore.java:197) [rt.jar:1.7.0_45]
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) [rt.jar:1.7.0_45]
        at java.util.concurrent.Semaphore.release(Semaphore.java:431) [rt.jar:1.7.0_45]
        at com.mongodb.util.SimplePool.done(SimplePool.java:129) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.util.SimplePool.done(SimplePool.java:103) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBTCPConnector$MyPort.done(DBTCPConnector.java:382) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:181) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:138) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:261) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:211) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBCollection.insert(DBCollection.java:57) [mongo-java-driver-2.7.3.jar:]
        at com.mongodb.DBCollection.insert(DBCollection.java:102) [mongo-java-driver-2.7.3.jar:]
Про NoClassDefFoundError — неверно, про остальные — не конец, но нередко (а OutOfMemоryError — практически всегда) признак того, что на надёжную работу JVM больше (до перезапуска) рассчитывать нельзя.
Что именно вы считаете неверным? Тот же slf4j при невозможности загрузить StaticLoggerBinder кидает NoClassDefFoundError (caused by ClassNotFoundException) при отсутствии имплементации логгера, но это не мешает пользовательскому софту продолжить работу без логгирования.

Такие же методы (ловля NoClassDefFoundError) иногда применяются при загрузке опциональных модулей.

P. S. Извините, считал, что вы отвечали на мой комментарий.
Я имел в виду, что неверно, что это «конец JVM».
То есть любой апплет в интернете может уронить мне JVM и вместе с ней браузер?
простите, не силен в апплетах. А причем тут браузер?
Ок, стоит уточнить, что подразумевается под «уронить». Одна из возможных интерпретаций — повреждение структур данных JVM в памяти с аварийным завершением процесса (если джава встроена в какое-нибудь приложение, браузер например, то все падает вместе). Я джавы не знаю совсем, но мне казалось что такой ситуации возникать не должно.

Странно что после переполнения стека нельзя поймать исключение, и продолжить дальше как ни в чем не бывало.
Иерархия ошибок в джаве делится на Exception и Error. Это наследники Throwable. У Exception есть еще наследник RuntimeException.
Так вот, Error и RuntimeException и их наследники классифицируются как unchecked exceptions. Их можно ловить тоже на самом деле. Но в случае с Error сложнее. Если самому выкинуть через throw new Error() — то можно поймать ошибку, обработать и продолжить работу. Но если ошибка брошена JVM — то нет. Поскольку машина выкидывает их, когда ей чего-то критически недостает(памяти) и она попросту не может функционировать.

Браузер не должен ломаться, когда ложится JVM. Просто апплет перестанет работать.
Итак, всем внимание. Ценная информация!

То что я изложил выше — это теория. На практике я уменьшил размер стека до 1 килобайта, а размер хипа до 2 мегабайт. В случае с пустым рекурсивным методом и с созданием большого количества объектов я получил ошибки StackOverflowError в первом случае и OutOfMemoryError во втором и смог их перехватить и обработать. Программа работает дальше!

Я так думаю, скорее всего просто не гарантируется корректная работа JVM после выбрасывания Error.
UPD:
Вот что пишет спецификация.
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.


Подтверждаю свое последнее предположение и иду спать спокойно )
То, что пустой метод занимает память и рекурсивный вызов кладёт JVM — не связанные факты. При бесконечной рекурсии стек переполнится из-за параметров и адресов возврата, а не байт-кода метода.
Подумал, и — да. Кажется ты прав. Это не связанные факты. Но это не меняет дела.
Когда я начинал разрабатывать на Java, я смотрел лекции Мирончика, где он в самом начале очень подробно рассказывает про то, как JVM работает с памятью и про загрузчики классов.

Сейчас я это порядком подзабыл, так как работаю в основном в уровнем повыше: Spring и подобное.
А код стараюсь оптимизировать на уровне алгоритмов.
Я, быть может, зануда, но единственно верный ответ на вопрос разработчику «оцените X по шкале от 1 до 10» это «уточните критерии оценки». Разработчик всегда должен уточнять нечетко поставленную перед ним задачу, а не выдавать первое попавшееся решение, формально соответствующее ТЗ.
Тут не угадаешь. Если речь на собеседовании и вопрос об оценке собственных знаний, это уже значит, что началось что-то мутное
Иногда может, наоборот, цениться умение «обходиться без лишних вопросов» и понимать «VIP»-а с полуслова…
100% зависит от собеседующего и его целей.
А в цели входят не только технические знания, но и человеческие качества.
Которые также проверяются подобными вопросами.

Так что если Вам задают подобный вопрос — вряд ли интересуются техническими знаниями.
Скорее — самооценкой, внимательностью и т.д.
UFO just landed and posted this here
Да нет тут никакого плана. Проблема в том, что все более-менее высокоуровнеые абстракции в IT протекают. И если у вас в команде 10 человек, твёрдо верящих, что «в Java не нужно думать об утечках памяти» и один эксперт, который знает не только что на самом-то деле таки иногда надо, но и когда об этом важно задуматься и что делать, чтобы разрулить проблемы вызванные GC (когда проблемы-таки возникают) — то всё в полном порядке. Когда ни одного такого эксперта нет — дело очень плохо. Простейшие проблемы, которые можно решить посмотрев на «живую» кучу приложения и обнаружив, что у вас короткоживущие переменные по какой-то причине уезжают в «долгую» кучу и вводят JVM в не совсем штатный режим работы, что приводит к резкой потере производительности будут отлаживаться годами.

Вот, собственно в статье и была описаны попытка нанять нескольких экспертов. Проблема же заключается в том, что по неизвестной науке причине куча разработчиков проработав лет 10 и так и не научившись разбираться с подобными хитрыми случаями начинает претендовать на звание «экспертов», больше ни в чём. Как уже было написано в статье: эксперт — это тот, кто что-то знает досконально, не «вширь», но «вглубь», а не тот, кто запомнил 100500 акронимов.

UFO just landed and posted this here
UFO just landed and posted this here
Типичный пример эффекта Даннинга-Крюгера.
Хороший специалист никогда не скажет, что он знает на 9 из 10. Никогда. И только посредственный специалист поставит себе высший балл, ведь он думает, что знает всё. В то время как отличный специалист с более глубокими знаниями понимает, что он знает далеко не всё.

Поэтому я никогда не доверяют оценкам, которые сами себе ставят собеседуемые. И вообще, забудьте про вопросы типа «на сколько баллов из 10 вы себя оцениваете» — всегда получите неадекват.
Ну как сказать… наверное, что-то из серии «вы просто не умеете их готовить»;-) В конце концов, можно просто выбросить результат ответа;-) оставит кандидата в размышлениях…
А по-моему ерунда в том, что под разными числами разные люди понимают разные смыслы. Если бы вместе с каждой оценкой шло бы пояснение, что она означает для вопрошающего, то и отвечающий смог бы подстроить свою картину мира под эти оценки, и дать более адекватный ответ.
Так кандат может заранее иметь такую оценку значениям:

5 — видел синтакс у соседа на экране
6 — пишу хелловорд без словаря
7 — знаю синтаксис
8 — пишу код
9 — пишу код и правлю свои баги
10 — правлю чужие баги и цитирую учебник

А собеседователь представляет все иначе, например:
6 — пишу код
7 — пишу сложные проекты
8 — офигенно пишу код и разбираюсь в тонкостях архитектуры и паттернах
9 — понимаю все низкоуровневые этапы работы
10 — разработчик языка

Ну собственно на мой взгляд это глобальная проблема с любыми числовыми оценками ( исключая +1 -1 в которых все довольно ясно ). Поэтому я не доверяю любым рейтингам в которых можно выставлять баллы ( так как у каждого человека в голове они расшифровываются в совсем иные конструкции ).
Ну как-то по-моему очевидно, что разброс примерно такой: 1 — ничего не знаешь, 10 — активный разработчик транслятора языка.
Активный разработчик транслятора языка — это, как правило, 9.
Пишите «вы» с маленькой буквы, выглядит по-дурацки и режет глаз.
Клиенты в ярости из-за непонятных проблем с производительностью? «Дайте мне полчаса».

Ищет лжецов-фантазёров?
UFO just landed and posted this here
60% проблем с производительностью решаются за пару месяцев до их появления… Если конечно следить за ними.
«99% статистических данных выдумывается тут же, из головы.»
Не ставлю под сомнение, но может есть где годные статьи на эту тему?
UFO just landed and posted this here
Индия, тысячи кандидатов… 'Торговец черным деревом" приехал на колониальный невольничий рынок. Товар с душком, зубы не те, и дороговато. Такое сложилось ощущение.
Бытует мнение, которое я разделяю, что связка современное железо + современные языки программирования всё ещё далеки от своих хоть сколько нибудь оптимальных реализаций, а IT индустрия, фундаментально, представляет из себя в гораздо большей степени исследовательскую область, нежели чем практическую. Если угодно это мой призыв растить специалистов более широкого профиля, готовых идти на эксперименты, и развивать базис для альтернативных подходов.
термин «специалист/эксперт» это прежде всего обобщение, а что не обобщай то результат всегда получается очень однобоким и неверным во многих случаях — это примерно тоже самое, что — все «мужчина/женщина/нацианальность/страна… такие то» — для кого-то эксперт это человек который способен решить чисто бизнес задачу техническими средствами (пусть даже и очень коряво), для кого-то человек который может решить чисто техническую проблему с «подковыркой» в очень специфичной области, для кого-то это просто человек который умеет работать в коллективе по его правилам и не нарушать «экосистему» и еще многочисленное число вариантов — по этому когда спрашивают подобные вопросы то в большинстве случаев вопрос об одном а ответ о другом.
В реальности востребованны все виды «специалистов» просто в разных областях, но вакансии на них чаще всего выглядят одинакого.

современные языки программирования всё ещё далеки от своих хоть сколько нибудь оптимальных реализаций

именно по этому на мой взгяд все не стоит на месте и постоянно развивается, чутли не каждый день появляется новый язык — это и хорошо и плохо,
тк очень похоже, что все пытаются решить общие проблемы по своему распыляя усилия
За всю мою практику мне все же как-то удалось уронить JVM с вылетом последней. JDK 5 HotSpot, насколько помню, это происходило при одновременном параллельном формировании OpenPGP ЭЦП с одним и тем же инстансом ключа. Вся реализация — 100% pure java. Выяснить причины падения удалось только благодаря трейсам при креше JVM. Вылетало где-то в недрах native-реализации (jvm, не 3rd party).
Мне кажется, важно знать, в чем именно «эксперт». Можно быть экспертом в ломании JVM, а можно знать, как построить с нуля сложную распределенную систему. Или быть экспертом в Spring. Но я согласен с автором, если заявляешь о себе как об «эксперте в Java», то детали JVM хорошо бы знать.
Sign up to leave a comment.

Articles