Comments 13
Для решения проблемы конкуренции с чтением файлов я реализовал простой кэш на основе Caffeine
Напомнило Яндексовую задачку на ревью кода про кэш. Тут тоже несколько потоков могут начать загружать одни и те же данные одновременно.
Механизм ServiceLoader языка Java спроектирован для обеспечения гибкости — он позволяет обнаруживать реализации в среде исполнения при помощи файлов
META-INF/services
Остался без ответа главный вопрос: ну что, сынку, помогли тебе твои ляхи она вам хоть как-то помогает, "гибкость" эта. Или это такой же гиммик, как независимость хибера от СУБД?
Слышал звон, да не знаю где он
Вообще не про то обе технологии, за которое пытаетесь их укоротить
Вы частично правы. Я не сразу понял, что этот DatatypeFactory из XML-кухни. Там тот еще enterprise fizz buzz, так что допущу, что именно так и нужно писать.
Ну а возможность смены СУБД без переписывания кода для хибера довольно часто подается как сильный аргумент в пользу сложных ORM-фреймворков. Хотя что-то мне подсказывает, что при переезде терабайтной базы с одного движка на другой проблемы с ORM будут на десятом плане.
Зачем вообще нужно было в разных потоках загружать одни и те же классы? Почему нельзя было выполнить их предзагрузку? Конечно, - это неоптимальное решение изначально. Я уж молчу про инстанцирование фабрики типов для каждого потока. Выглядит как мы сами создали оружие для выстрела себе в колено, а потом героически собрали коленную чашечку и закопали ствол на заднем дворе от греха подальше. Механизм загрузки классов не предназначен для быстрой обработки данных.
Спасибо за статью. Полезный опыт, особенно для относительно долгоживущих проектов в котором побывало много шаловливых ручек
Рекомендую async-profiler вместо дампа потоков, наглядно будет видно всё происходящее без необходимости применять интеллект.
В чем отличие от VisualVM? Вы же не про Lock profiling?
Нет, в данной ситуации я бы использовал wall-profile. Ключевых отличий для нашего случая как минимум два:
Async-profiler может показывать граф вызовов вплоть до ядра, а не только java-часть.
Возможность визуализации в виде хитмапа с возможностью дальнейшего анализа и сравнения флеймграфов за произвольный период.
Также в некоторых случаях async-profiler показывает значительно более высокую точность профиля, т.к. проектировался как раз в т.ч. для патологических corner-case'ов.
В любом случае, главная часть моего утверждения: специализированный инструмент (профайлер) лучше ручных дампов потоков.
Спасибо за статью и за то что поделились опытом.
В нормальной ситуации любые порождающие классы в критичных блоках должны пристально изучаться на код-ревью и уже там должен был возникнуть вопрос "а нафига?". Ну а раз не возник - героически расследуем и побеждаем, че уж. Честно говоря, не понимаю, о чем статья? Обычная ежедневная работа senior программиста в большом legacy
Одна строка кода, которая заблокировала 102 потока