4055
Вход в Айтишную - https://t.me/+SMtf609BHIGaMarf Можно обсуждать с матом и без всё, что касается жабы, вплоть до холиваров. ПРАВИЛА - https://t.me/javarush/229767/ НЕ ИМЕЕТ ОТНОШЕНИЯ К САЙТУ JAVARUSH.RU
Пробую OAuth2 от Keycloak для работы с MCP сервером.
Застрял на:
MCP Inspector is sending the custom header mcp-protocol-version to Keycloak's OAuth discovery endpoint.
Keycloak's CORS response does not allow that header.
Привет, можете пожалуйста одолжить ссылки на репозитории с качественным применением DDD, если есть
Читать полностью…
Что-то я сомневаюсь, что в ИП, о котором только записи в реестре гуглятся, будет хороший коммерческий опыт. Конечно, я Беларуси всё может быть
Читать полностью…
Зачем на такую работу идти? Ни денег, ни менторства. Ради портфолио?
Читать полностью…
- проект на данный момент не приносит доход, поэтому оплата минимальная (чисто формальная).
- ментора с коммерческим опытом на проекте сейчас нет.
Спасибо за примеры, но как заметил дедфейс - это скорее про общую компьютерную грамотность и реализацию ее принципов в жвм.
Кроме некоторых жава специфик приколюх, вроде конкатенации строк и базы, вроде тредов.
Ну и я не говорил, что знать жвм не нужно:)
1. Потрясающий пример. В нем понимание жвм наоборот развязывает руки и разрешает конкатенировать строки сколько хочешь (этот момент давно оптимизировали), вопреки устаревшей пугалке про память. Исключение - если у тебя все ещё восьмая джава.
Эрейлист эффективен на вставках за счёт нативного кода, который используется при копировании массива. Если для понимания этого ты лезешь в жвм и кеш линии процессора, то ты начал немного не оттуда
2. Тут каша какая-то: есть дорогие потоки (классические треды) - эта проблема решается переходом на реактор/лум. Есть обработка данных - она решается форматом данных. В первом случае достаточно базового понимания жвм, согласен. Во втором он вообще ни к чему
3. Все, что тебе нужно знать из жвм, это то, что потоки дорогие, но есть и дешёвые потоки, а ещё бывает ивент луп
4. Тебе не нужно понимать жвм, чтобы понимать, что грузить все в память - не всегда хорошая идея
Твоя позиция мне понятна - можно писать на Java без понимания JVM. так же как можно водить машину, не разбираясь в двигателе. нно когда машина ломается на трассе (OOM в продакшене в 3 часа ночи) или когда нужно выиграть гонку (выдержать SLA под пиковой нагрузкой) - знание механики маст хе. Особенно(!) в микросервисной архитектуре где каждый сервис - это JVM-процесс со своей кучей, потоками и характеристиками GC.
это знание отличает систему, которая работает, от системы, которая работает Надежно(!) под нагрузкой.
P.S. тебе и всем "исключительно кодерам" планеты - вы в жопе. АИ уже пишет код лучше всех вас вместе взятых. У вас осталось 2 выхода - либы переквалифицироваться в настоящего инженера, умеющего находить решения + думать головой, разбираться в спецификациях и направлять(!) АИ в нужное русло - или искать себе другую професию.
Доклад закончил, всю запрошенную информацию тебе разложил, дальнейшее развитые темы считаю нецелесообразным. Хорошего дня
Как мне понимание жвм поможет выбрать алгоритм, докер имедж без ждк, протокол коммуникации? При чем тут батчи и синк/асинк?
Ты вопрос то мой видел?
Все возможные варианты вопросов на собесах?
Полного списка не существует, на собеседованиях же вопросы не из сборников задач берут
Могут спросить что угодно и уйти в любые глубины, начав спрашивать детальнее по одной теме, если видно что вы "плаваете" в базовых вопросах, или наоборот скипнуть большинство вопросов по другой теме, потому что сразу понятно что тут у вас достаточно опыта
GitHub - enhorse/java-interview: Вопросы и ответы к интервью Java разработчика · GitHub https://share.google/1CvEVZex8bKJI9dVx
Читать полностью…
Ребята, добрый день. Подскажите, пожалуйста, где можно опубликовать вакансию Senior Java Developer с хорошим разговорным английским в Москве? Буду очень благодарна за советы.
Читать полностью…
Поэтому я и решил спросить у более знающих людей, которые в этом варятся.
Читать полностью…
Такой опыт будет будет равноценен пет проекту. Ты от такого сотрудничества не получаешь ничего.
Читать полностью…
Что там за проект, которому не нужны опытные разработчики? Кнопки красить? )
Читать полностью…
Всем привет! Такой вопрос.
Кто нить слышал про такого человека, Гаврыш Георгий Александрович
часто публикует вакансии на стажера разработчика
но я нигде не смог найти отзывы.
Может кто сталкивался?
Окей, чтобы вы не обижались, по порядку:
Дед фейс:
Ты по сути говоришь: "всё это не JVM, а просто здравый смысл." Но здравый смысл о потоках, памяти и сериализации - это и есть понимание JVM-рантайма. Ты прав что протобаф легче JSON не изза JVM а изза формата . Но выбор между tree и streaming парсингом - это решение мотивированное тем, как конкретно JVM аллоцирует объекты и когда GC их собирает. В Go, Rust или C++ ровно те же слова ("не грузи всё в память") имеют совершенно другую механику и другие решения.
Volodymyr:
По строкам - ты частично прав. Начиная с Java 9 JVM может оптимизировать конкатенацию в цикле значительно лучше. Но "оптимизировали" не значит "можно не думать" - в горячем цикле с большими строками разница всё ещё измерима. И самое главное: откуда ты знаешь, что это оптимизировали? Из понимания JVM (или кому-то в интернете на слово поверил?). Ты сам опровергаешь свой тезис.
По ArrayList - ты говоришь "эффективен за счёт нативного кода при копировании массива" (System.arraycopy). Верно. Но почему System.arraycopy быстрый? Потому что JVM интринсифицирует его в прямую операцию с памятью, минуя bounds-checking поэлементно. Это знание JVM-интринсиков. ты опять используешь знание JVM, чтобы доказать,что знание JVM не нужно.
По потокам - "достаточно знать, что потоки дорогие, и есть дешёвые" - это как сказать "достаточно знать, что бензин дорогой, и есть электричество." Ладно, а почему дорогие? Почему виртуальные потоки дешёвые? Почему реактор работает иначе? Без модели того, что происходит в рантайме, это карго-культ: "мне сказали использовать Loom, я использую Loom."
Ваша проблема ребят, в том что вы путаете два утверждения:
- "Мне не нужно читать исходники HotSpot, чтобы писать CRUD" - верно
- "Мне не нужно понимать, как JVM управляет памятью, потоками и GC" - неверно
Никто не просит в тонкостях знать устройство C2-компилятора. Но когда в три часа ночи прод падает с OOM, или latency p99 улетает в секунды, или батч-джоба не укладывается в окно - "здравого смысла" без модели рантайма не хватит. Вы будете тыкать наугад: увеличить Xmx? Добавить потоков? Перезапустить?
Что касается моего последнего предложения предыдущего сообщения (на которое ты Volodymyr отреагировал картинкой) - это логическая реакция на твой тон ("ты вопрос то мой видел?") - это уже не про JVM, это про культуру обсуждения в общем чате. Если человек спрашивает "зачем мне X" получает развёрнутый ответ с примерами, а потом переходит к "при чём тут это всё" - то ты не спрашивал. Ты утверждал. И тут уже вопрос не технический, а вопрос в подходе: стоит ли продолжать убеждать, или зафиксировать позицию и двигаться дальше.
А где жвм в твоих примерах?
Есть какой-то язык/платформа где
1) аллокация кучи мелких кусков памяти очень быстрая + связный список кешируется процом?
2) dom быстрее sax, а протобаф жирнее жсона?
3) запуск 500 потоков автоматом сделает программу быстрее(ладно, в человека который в такое поверит я могу поверить сам)
4) 10x данных не увелчивает нагрузку?
1.
НапримерString result = "";Чувак без знания JVM видит «конкатенацию строк» - а JVM видит N аллокаций прогрессивно растущих массивов
for (String s : items) {
result += s + ",";
}char[] в куче, каждый из которых копируется из предыдущего, превращая задачу O(n) в O(n²) по памяти. Знание того, что String - иммутабл объект и что += компилируется в новый StringBuilder на каждую итерацию - это знание JVM, а не просто «синтаксиса Java».
Другой пример:
Чел без знания JVM может использовать LinkedList, потому что «это же список» не понимая, что JVM раскладывает его узлы как разбросанные по куче объекты, уничтожая локальность кэша. ArrayList с непрерывной памятью может обогнать его даже при частых вставках ниже определённого размера - чисто из-за того, как JVM взаимодействует с кэш-линиями процессора. Без понимания расположения объектов и аллокации в куче об этом невозможно рассуждать.
2.
Когда сервис вызывает другой сервис по HTTP, JVM управляет пулами потоков, буферами сокетов, пулами соединений и сериализацией - и всё это имеет последствия для памяти и сборки мусора.
Представим сервис, который десериализует JSON-ответ размером 2 МБ от другого сервиса в глубокий граф объектов. Это создаёт сотни или тысячи короткоживущих объектов в куче. При 500 запросах в секунду это огромная нагрузка на GC. Чувак скажет «Jackson всё запилит» - но человек понимающий JVM задаст вопрос: может стоит использовать потоковый парсинг вместо древовидного? Более компактный формат передачи, например Protobuf, который создаёт меньше промежуточных объектов?
Тюнинг пула соединений и настройка таймаутов (удерживание потока в 1МБ и накопление оных) в ту же степь.
3.
Чел без знания JVM может запустить 500 потоков, думая «ОС сама разберётся». JVM не просто передаёт потоки операционной системе на халяву
каждый поток аллоцирует стек (по умолчанию 1 МБ через -Xss). 500 потоков = 500 МБ памяти за пределами кучи, ещё до того, как ты сделал хоть что-то полезное. Эта память не управляется GC, но JVM всё равно нуждается в ней.
Стоимость переключения контекста усугубляет проблему. Когда ОС перебирает 500 потоков, процессор тратит значительное время на сохранение состояния регистров и сброс кэшей. JVM не может оптимизировать код, который никогда не выполняется достаточно долго, чтобы быть JIT-компилированным в горячий цикл.
4.
Представим ночную таску, которая читает 10 миллионов строк из базы данных и трансформирует их. Наивная реализация загружает все строки в List<Entity> - это потенциально ГБ живых объектов в куче. GC должен сканировать их все при каждом цикле сборки, и если ты превышаешь old generation, ты получаешь паузы полной сборки мусора длительностью в секунды или минуты.
Ещё один реальный пример: батч-задача работает нормально в деве со 100К записей, потом падает с OOM в проде с 10М записей. наивный чувак увеличивает -Xmx до 16 ГБ (и это клиенту еще продать надо). Задача ранится но теперь имеет по 8 сек паузы GC во время полных сборок. Человек со знанием JVM вместо этого исправит код, чтобы не держать 10М объектов одновременно, выставит правильные флаги GC и возможно добавит -XX:+HeapDumpOnOutOfMemoryError для диагностики реального пути удержания объектов.
После анализа ресурсоемкости системы и первых лоад тестов, вопрос с производительностью неприятно может зависнуть в воздухе. Особенно если ресурсов клиент себе больше позволить не может.(Поверь друг мой, особенно на аутсорсе, сейлы а потом и менеджеры продадут все так, что ты ужом должен будешь извернуться чтобы на минимально возможных ресурсах сделать производительную систему.)
И когда твой тех-лид/архитектор/кьюа будут перепроверять соответствие твоих сервисов с установленными НФРами на проекте - они придут к тебе.
В независимости от того по каким причинам ты не сразу писал оптимизированный код/не советовался с техлидом и т.п. - переписывать это придется тебе. С учетом того что в реальной практике у тебя будет еще и своих задач по горло, которые нужно успеть перед релизом - по головке тебя не погладят. Знаю случаи когда людей которые до такого дотянули - увольняли с работы в срочном порядке.
Мест где нужно понимание как минимум JVM немало:
- код программы (выбор алгоритма для написания точечного метода: time/space complexity)
- правильный подбор докеимеджа (не пихать JDK в бейз без острой необходимости )
- балансировка меж сервисных коммуникаций (на базе разных протоколов, их влияние на создание потоков пулов веб сервера)
- выбор фреймворков и тулингов для узконаправленых сервисов (батчи, асинки)
- анализ производительности - умение работать с мониторинг тулами. (Егерь, графана, visual VM etc.)
Чем больше вещей из списка ты пропустишь - тем тяжелее это будет наверствывать. Поэтому тебе перед тем как приступать к работе - нужно сразу задумываться о том чтобы писать код качественно. С поверхностными знаниями ты этого не осилишь.
есть канал типо "реальные задачи с собеседований"
можешь там глянуть
Посоветуйте, пожалуйста, ресурсы, на которых можно взять перечень теоретических вопросов и практических заданий для подготовки к собеседованию Java
Читать полностью…
Автор про жвм спросил, я тоже, чуть дополнив.
Если ты имел ввиду синтаксис и стандартные библиотеки - вопросов нет.
Если ты настаиваешь, что для написания норм кода нужно понимание гц/жвм/компилятора/т.п. - я бы почитал подробности