• 0
    Я бы не сказал. Вот тут (не очень детальное) представление того, что тормозит сильнее всех: https://plumbr.eu/blog/performance-blog/most-frequent-performance-bottlenecks

    TL;DR:

    1. HTTP запросы к даунстримам
    2. Lock contention
    3. JDBC вызовы
    4. JDBC пулы коннекшнов
    Современный подход к сборке мусора
  • 0
    То есть в svn можно отдельно взятые ревизии перетащить из транка в релизную ветку? В целом, спасибо за информацию. У меня от svn только воспоминания баттхёрта, но я им никогда и не учился правильно пользоваться :)
    Java DevTools: модно не значит хорошо
  • +2
    А из транка нужные фичи как выбираются? Cherry picking? А всякие svn-ы так умеют, или нужно вручную конкретные файлы переносить? А если две фичи один и тот же файл изменяют? А если команда больше и фич в разработке много?
    Java DevTools: модно не значит хорошо
  • +1
    Ага. Нужен очень надёжный механизм включения/ выключения :) Это, конечно, и для других целей полезно будет. Но нельзя же все изменения делать отключаемыми? Сложный багфикс, например, может занять несколько дней и в промежутке система может быть в разбитом состоянии. Или крупная переделка в некоторых частях сразу.

    А какие популярные и железобетонные подходы к отключению фич ты пробовал?
    Java DevTools: модно не значит хорошо
  • +1
    Вообще слабо представляю, как можно разрабатывать в основной ветке и спокойно спать, разве что если релизить раз в месяц.

    Есть две фичи: одну делать две недели, другую одну неделю. Как зарелизить вторую фичу через неделю и быть уверенным, что work in progress первой фичи ничего не сломает? При использовании feature branches — легко. Но если коммитить открыто и смело и прямо в trunk, то будет тяжеловато.

    Случайно поставил минус комментарию, сорян
    Java DevTools: модно не значит хорошо
  • +2
    Довольно распространённая техника у enterprise продажников. Даже мы что-то такое пробовали. Потом в дурку забраПотом поняли, что продавать систему мониторинга нужно не через инженеров, и совсем поменяли стратегию.
    Java DevTools: модно не значит хорошо
  • +2
    Я, кстати, когда первый раз запускал js-тесты в проекте, думал, что что-то не так сделал, потому что они моментально отработали. Оказалось, что они и правда безумно быстро пробегают.
    Производительность Java: настоящее и будущее
  • +10
    Подождите, вы хвалите NodeJS, но при этом хаяете Java за то, что там GC и JIT? Или я не так понял?
    Производительность Java: настоящее и будущее
  • +4
    Вы действительно считаете, что веб-серверы — не частый пример использования? Такое ощущение, мы с вами живём в разных мирах. Если не считать инструментов разработки, то у меня практически нет десктопных приложений. Я каждый день пользуюсь десятками, если не сотнями разных веб-приложенией. И у многих из них, не только у «корпорации гугл» миллионые дневные аудитории. И многие из этих веб-сервисов счастливо бегают в JVM. Это огромная ниша.

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

    Это, конечно же, никак не уменьшает роль других элементов в стеке технологий: тех же bash-скриптов, которыми зачастую эти приложения деплоятся, или написанного на С linux, на котором всё это часто запущено. Но нельзя просто так сказать, что веб-серверы никому не нужны.
    Производительность Java: настоящее и будущее
  • +3
    Чтобы спустя год с лишним кто-то, кому нужно в тестах получить metaspace oom, используя как можно более крупные классы (а не, например, много мелких), вспомнил эту прекрасную статью, и сэкономил кучу времени. Спасибо тебе, lany!
    Как растаращить class-файл
  • +1
    Ты, кстати, осчастливишь нас своим присутствием, наконец?
    Простые задачи на Java. Слабо решить все?
  • +1
    К слову, если добавить достаточно циклов, чтобы ворвался компилятор, тоже много чего интересного начинается ;)
    Простые задачи на Java. Слабо решить все?
  • +4
    Oops. Тут должна была быть надпись «Класс!», подкреплённая unicode-символом с вытянутым вверх большим пальцем. Но что-то пошло не так :)
    Класс дедлоков про дедлок классов
  • +2
    Это проценты от запусков приложений, в которых мы задетектили OOM. Приложения и среды самые разные. Java 8 среди них действительно не очень много.

    Согласен, что иногда может быть полезно. Однако в общем случае продолжать работу при OOM — дело опасное. Даже если всю память отожрал именно конкретный try-блок, схватить OOM при этом могут и совершенно не связанные с ним места, оставшись в некорректном состоянии.

    Насчёт NoSuchMethodError согласен. Насчёт слать смску — есть много весьма умных систем мониторинга, да :)
    Как бороться с OutOfMemoryError на практике, или ох уж мне эти базы данных
  • +2
    Замечательная статья!

    Могу добавить немного интересной статистики. Хоть она и основана на сотнях разных клиентских приложений, выборка может быть несколько смещённой, так что стоит относиться осторожно.

    Около 40% приложений с OOM падают с message «Java Heap Space». Около 20% падают с «GC overhead limit exceeded». Около 20% падают с «PermGen space».

    Больше 50% приложений имеют только один OOM за всё время жизни процессы, 90% приложений имеют 14 OOM или меньше. Остальные могут кидать их сотнями, некоторые даже сотнями тысяч. Weblogic в этом плане бьёт все рекорды со своим catch(Throwable t). Пара-тройка OOM для одной JVM это нормально при нескольких активно аллоцирующих потоках.

    Около 90% приложений завершается в течение 10 минут после OOM, около 70% погибают в течение минуты. Остальные могут жить днями, неделями и даже месяцами (хотя зачастую помимо бросания OOM ничего толкового и не делают).

    Около 50% приложений с OOM получают его в первые полчаса своей работы. Около 10% вылетают прямо при старте.

    В примерно 70% случаев память перед OOM сжирается медленно, но верно. В большинстве остальных её сжирают в один резкий присест.

    Также могу порекомендовать handbook по разным типам OOM (не сочтите за пиар :) )
    Как бороться с OutOfMemoryError на практике, или ох уж мне эти базы данных
  • 0
    Да, статья отличная. На неё даже уже есть ссылка в этом топике, но разместить её ещё раз не помешает :)
    А как же всё-таки работает многопоточность? Часть II: memory ordering
  • +3
    Как сторонник аргументированных обсуждений не могу пройти мимо вашего комментария. Чтобы понять логику ваших рассуждений, позвольте уточнить несколько моментов:

    А как тогда, по Вашему у объектов, существующих одновременно в нескольких потоках, ссылки подсчитывются? ;) Будет же «застревать в кэше» счётчик ссылок? :)

    О каком счётчике ссылок идёт речь?

    Кроме того — завершение секции synchronize приведёт к записи переменной, т.к. является барьером синхронизации в Java, разве нет?

    С чего вы взяли, что «секция synchronize» является барьером синхронизации? Что вы вообще имеете в виду под «барьером синхронизации»? В терминах JMM, если можно.
    Ещё раз (надеюсь, последний) про double-checked locking
  • 0
    Ходил на квест Киберпанк, очень понравилась матрица :)
    Монетизация Oculus Rift и Leap motion в квестах в реальности
  • 0
    Понял ваш ход мыслей, спасибо.
    Элегантный Builder на Java
  • 0
    Ок, первое вижу. А остальное? Исходя из каких убеждений вы сделали эти утверждения?
    Элегантный Builder на Java
  • +3
    Не сочтите за грубость, но мне искренне интересно, почему вы считаете, что:

    Модификатор final используется только на этапе компиляции. В байткоде его нет и JVM про него ничего не знает.


    Даже если компилятор поменяет порядок внутри метода, ни один конкурентный поток не увидит ссылку на недостоенный объект.


    Разве что компилятор решит сделать inline методу, хотя я уверен, что на публичный метод у него рука не поднимется.


    Серьёзно, основываясь на чём вы делаете такие утверждения с такой уверенностью?
    Элегантный Builder на Java
  • +2
    Пока что единственный ваш аргумент в пользу книги вот тут, и из него нельзя вынести ничего, кроме того, что лично вам она, вероятно, понравилась. Я читал несколько отрывков оригинала, и мне было очень грустно от того, что из-за того, как убедительно для обывателя пишет автор, огромное число этих самых обывателей начнёт верить в подобные заблуждения. Представляете, я открыл её, и мне она всё равно показалась бредом. Как и многим, многим другим, которые имеют куда более профессиональное отношение к предметной области.

    Так что же, расскажите всем, почему именно вы считаете эту книгу достойным перевода, места на прилавке и поста на хабрахабре?
    Биоцентризм. Как жизнь создает Вселенную
  • +3
    Мне вот очень жаль переводчиков. С высокой вероятностью они испытали ужасную фрустрацию от того, какие высеры им приходится переводить. Тоже довольно вероятно, что они этим высером прониклись, и страдать будут ещё и окружающие их люди. В общем, молодцы, ph_piter, вы сделали мир хуже, издав это на другом языке.
    Биоцентризм. Как жизнь создает Вселенную
  • +3
    anton написал:
    Если эти пропавшие люди — основоположники статистического машинного обучения — пост здесь даёт шанс их спасти, почему нет?

    Но это не значит, что он подразумевал то, что написали вы:
    Если просто пропали и ничего не знают они про статическое машинное обучение, то х%№ с ними, да?!

    Ведь «A -> B» не эквивалентно «¬A -> ¬B», правда?

    Однако ваш комментарий создал у gnomeby впечатление, будто вы решили, что anton считает, что тех, кто «ничего не знают они про статическое машинное обучение», «нафиг искать». Поэтому он указал вам на возможность того, что вы совершили типичную логическую ошибку под названием «Приписывание утверждений».

    Теперь понятно?
    Нужна помощь: пропал Алексей Червоненкис
  • 0
    Юзернейм интересный ;)
    Занимательный web-квест. Узнай весь URL
  • +2
    Забавно, решения практически одинаковые :)
    habrahabr.ru/post/234945/
    Возвращаем дочерний класс из родительского. Факультатив
  • 0
    Можешь этот минусануть взамен!
    Ахаха, HotSpot, что ты делаешь, прекрати!
  • 0
    Ты не был понят широкими массами. Да и мной тоже :)
    Ахаха, HotSpot, что ты делаешь, прекрати!
  • +5
    Ознакомьтесь, пожалуйста: shipilev.net/talks/j1-April2013-benchmarking-II.pdf и shipilev.net/talks/jeeconf-May2014-benchmarking.pdf
    Серьёзно, сделайте это. Если после этого не поймёте всего масштаба заблуждений, которые можно наблюдать в этом посте, пишите.
    Сравнение скорости работы ArrayList и LinkedList на практике
  • +1
    Точно. Инвайт ваш :)
    Ахаха, HotSpot, что ты делаешь, прекрати!
  • 0
    Почти! :)
    Но ведь патчем затронуты и vmCMSOperations.hpp и vmPSOperations.cpp, а не только vm_operations_g1.hpp. Почему один даёт "unknown GCCause", а другой — "No GC"?
    Ахаха, HotSpot, что ты делаешь, прекрати!
  • +1
    Логично было бы ещё зарядку сделать беспроводной. Понимаю, что может быть сложно совместить с левитацией, но всё же.
    Om One: левитирующий Bluetooth-динамик