Чем отличается Servlet Container от Application Server?

JavaEE – это стандарт, набор соглашений. Разделяется на множество отдельных самостоятельных спецификаций технологий. В JDK поставляется в виде только интерфейсов и документации, но не их реализации.

Application Server – это полная реализация всех спецификаций стандарта JavaEE: распределенные транзакции, EJB, пуллинг соединений к БД и т.д.. Используется для хостинга полноценных enterprise-приложений (.ear). Примеры – JBoss, TomEE, Glassfish, WebSphere.

Servlet Container (web server) – это реализация минимальной необходимой части JavaEE – Servlet API и JSP. Умеет хостить статический контент, jsp-страницы и выполнять Java код сервлетов. Остальные спецификации JavaEE при необходимости добавляются сторонними библиотеками-реализациями. Примеры – Tomcat, Jetty.

Каждый сервер приложений содержит в себе контейнер сервлетов. Spring Framework – альтернатива JEE, поэтому для запуска приложения на основе Spring обычно достаточно веб-контейнера. Если же приложение использует всю мощь JEE, необходим сервер приложений.


👉@BookJava

Как получить текущий метод


В общем виде задача сводится к получению текущего стек-трейса, и взятию его верхнего элемента. Гарантированного способа не существует, потому что JVM имеет право «терять» фреймы стека (то есть методы цепочки вызовов) при оптимизации.

1. new Exception().printStackTrace(printStream)
Печатает стек-трейс в текстовом виде в поток. Первой строкой выводится toString() объекта Exception, далее стек вызовов до места создания исключения. Соответственно, из потока нужно будет достать и распарсить вторую строку. В зависимости от JVM формат вывода может отличаться.

2. Thread.currentThread().getStackTrace()

3. new Exception().getStackTrace()
Более красивые способы. Возвращают уже массив готовых объектов-фреймов, нужно только взять первый элемент. Эти вызовы дорогие, они всегда загружают весь стек, даже если нужен первый фрейм. От класса-владельца метода в возвращаемом StackTraceElement доступна только строка имени, для доступа через Reflection придется загружать его вручную.

4. StackWalker.getInstance(options, depth).walk(s -> ...)
Самый продвинутый способ, доступный с Java 9 – специально предназначенный для этого класс. Параметрами метода getInstance() можно ограничивать необходимую глубину и детализацию стека. Результаты – экземпляры StackFrame – содержат готовый для рефлекшна Class<?> вызывающего объекта.

👉@BookJava

10 лучших практик производительности Spring Boot

Spring Framework - один из самых популярных и известных фреймворков для разработки приложений в экосистеме Java, а Spring Boot упрощает процесс создания приложений на базе Spring, предоставляя предварительно настроенные модули, автоматическую конфигурацию, стартовые зависимости и многое другое. Такая простота, популярность и стабильность привели к тому, что многие системы были реализованы с помощью Spring Boot, и вполне возможно, что некоторые из них не оптимизированы и не производительны.

В этой статье мы сначала обсудим, что такое производительность в целом, а затем рассмотрим 10 лучших практик производительности Spring Boot, чтобы сделать наш Spring Boot быстрым и ресурсоэффективным.


https://digma.ai/10-spring-boot-performance-best-practices/

👉@BookJava

Как используется метод Lock.newCondition()?

Если реализации интерфейса Lock представляют высокоуровневую альтернативу блока synchronized, то реализации его спутника, интерфейса Condition – альтернатива методам notify/wait. Оба этих интерфейса относятся к пакету java.util.concurrent.locks.

Как и ожидание на мониторе, Condition реализует примитив синхронизации «Условная переменная». Один или несколько потоков зависают на объекте-кондишне с помощью варианта метода await (ждут удовлетворения условия). Другой поток пробуждает их методами signal и signalAll (сигнализирует об удовлетворении условия).

Конкретные реализации Condition всегда решают те же задачи, что блокировка на мониторе, но в теории могут отличаться в нюансах поведения. Например, может не быть требования вызывать ожидание/сигнал только при захваченном локе (аналог требования, по которому notify/wait всегда вызываются в synchronized). Или может гарантироваться порядок получения сигнала ожидающими потоками.

Возвращаясь к поставленному вопросу, Condition всегда связан со своим объектом типа Lock, и метод Lock.newCondition() – единственный правильный способ создания кондишна.

👉@BookJava

Как из Java приложения запустить другую программу?

Самый простой и базовый способ – с помощью метода Runtime.getRuntime().exec(). В качестве параметра ему передается строка системной команды. Опциональные можно передать рабочую директорию, и переменные окружения в виде массива строк "имя=значение". Если команде нужны аргументы, они передаются либо массивом, либо в той же строке команды через пробелы.

Рекомендуемый, и более управляемый способ – использование класса ProcessBuilder. Он же применяется внутри метода exec. Билдер дает, например, средства для использования в команде пайплайнов и редиректов ввода-вывода.

В результате запуска команды создается объект класса Process. Его можно сконвертировать в более современный (Java 9+) и функциональный ProcessHandle. Через эти объекты идет работа с вводом-выводом процесса, его характеристиками и статусом.

Команда запускается в отдельном подпроцессе операционной системы. Это значит, что лозунг «Write once, run anywhere» перестает здесь работать – ваша программа становится платформо-зависимой. Обращение к ОС, а тем более выделение нового процесса обычно занимает немало ресурсов компьютера. Запуск внешних программ не считается плохой практикой, но всё-таки при возможности стоит его избегать.

👉@BookJava

Устойчивость микросервисных Spring приложений: роль аннотации Transactional в предотвращении утечки соединений

В любом микросервисе четкое управление взаимодействием с базой данных является ключевым фактором для поддержания производительности приложения и его надежности на должном уровне. Обычно мы натыкаемся на странные проблемы с подключением к базе данных во время тестирования производительности. Недавно мы обнаружили критическую проблему внутри слоя репозиториев в нашем микросервисном Spring приложении: неправильная обработка исключения приводила к неожиданным сбоям и нарушению работы сервиса во время тестирования производительности. Эта статья представляет собой анализ проблемы и рассказывает, как она была решена с помощью аннотации @Transactional.

Микросервисные Spring приложения сильно зависят от стабильного и эффективного взаимодействия с базой данных, которое часто осуществляется через Java Persistence API (JPA). Для поддержания высокой производительности важно правильно управлять пулом соединений и предотвращать утечки соединений, чтобы взаимодействие с базой данных не снижало производительность приложения.

https://habr.com/ru/companies/spring_aio/articles/827642/

👉@BookJava

How-to Build Custom Java Runtimes with Jlink.

Видео о создании пользовательского образа среды выполнения с помощью инструмента командной строки jlink. Создается образ, который содержит только те модули, которые нужны приложению, что уменьшает размер приложения и повышает безопасность.

https://www.youtube.com/watch?v=mJKlxqQQeyI&t=52s

👉@BookJava

Зачем выбирать ReentrantLock вместо synchronized?

Объект класса ReentrantLock решает те же задачи, что и блок synchronized. Поток висит на вызове метода lock() в ожидании своей очереди занять этот объект. Владеть локом, как и находиться внутри блока synchronized может только один поток одновременно. unlock(), подобно выходу из блока синхронизации, освобождает объект-монитор для других потоков.

В отличие от блока синхронизации, ReentrantLock дает расширенный интерфейс для получения информации о состоянии блокировки. Методы лока позволяют еще до блокировки узнать, занят ли он сейчас, сколько потоков ждут его в очереди, сколько раз подряд текущий поток завладел им.

Шире и возможные режимы блокировки. Кроме обычного ожидающего lock(), вариант tryLock() с параметром ожидает своей очереди только заданное время, а без параметра – вообще не ждет, а только захватывает свободный лок.

Еще одно отличие – свойство fair. Лок с этим свойством обеспечивает «справедливость» очереди: пришедший раньше поток захватывает объект раньше. Блок synchronized не дает никаких гарантий порядка.

👉@BookJava

Совет Spring Framework💡

Вы можете инжектировать (autowire) бины, которые могут отсутствовать, обернув их в java.util.Optional. Таким образом вы сообщаете, что этот бин является необязательным, избегаете исключения, если он не существует, и можете аккуратно обработать его отсутствие с помощью Optional API.

👉@BookJava

Курс по Kubernetes для разработчиков. Видеокурс по Docker в подарок ⤵️

❓ Ваша компания решила мигрировать сервисы на Kubernetes?
❓ Большая часть интересных вам вакансий требует навыков в K8s?
❓ Вы не врубаетесь, где границы ответственности девопсов и разработчиков в работе с кубами?

Разбираемся с этим на курсе Слёрма «Kubernetes для разработчиков» 😎

Старт потока — 22 июля. 

ПРОГРАММА КУРСА

Вас ждут:
✅ 7 недель обучения 
✅ 112 часов практики + 26 часов теории
✅ Общий чат со студентами, экспертами и куратором
✅ Стенды для отработки практических навыков
✅ Сдача сертификации
✅ Итоговый проект

Эксперты — действующие devops-инженеры:
➡️ Марсель Ибраев, Senior System Engineer G42 Cloud
➡️ Павел Селиванов, архитектор Yandex Cloud

🎁 При оплате обучения до 22 июля — видеокурс по основам Docker в подарок🎁

🔗 ПРОЙТИ ПЕРВЫЕ ТРИ УРОКА БЕСПЛАТНО

Совет 💡

Если вы хотите получить сообщение о первопричине, вы можете легко и безопасно получить его с помощью Apache Commons ExceptionUtils. Методы getRootCauseMessage(Exception ex) выдают сообщение в виде {ClassNameWithoutPackage} {ThrowableMessage}

👉@BookJava

⚛️Росатом ищет разработчиков на позицию Backend Developer (Java) HR TECH в Гринатом (IT-интегратор Росатома)

Требования: опыт разработки и поддержки микросервисов на Java; опыт работы с реляционным базами данных (PostgreSQL); опыт проведения Сode Review; знание основных методологий разработки программного обеспечения, принципов OOП, шаблонов проектирования, принципов SOLID, DRY, KISS; практика использования Test Containers в интеграционных тестах; отличное знание Spring/Spring Boot (Core, MVC/Webflux, Data/Integration, Security, Actuator, Auto configuration, AOP); опыт работы с Kafka; хорошее знание Maven/Gradle и CI/CD систем(Gitlab/Jenkins); профилирование кода, анализ дампов памяти, анализ логов, метрик и трассировок, тонкая настройка JVM.

Мы предлагаем: полностью удалённую работу на территории РФ или рабочее место в уютном офисе; конкурентную ЗП и премии, оформление по ТК с удобным графиком, выбор между удалёнкой и офисом, карьерный рост, ДМС со стоматологией, собственную платформу для обучения, конференции и тренинги.

👉Узнать подробнее и откликнуться можно по ссылке.

Как отладить удаленное приложение?

Если приложение работает не в продакшне, его паузы допустимы, а у потенциального злоумышленника нет сетевого доступа к хосту, стандартный способ отладки – непосредственно remote debug. Для этого приложение запускается с включенным протоколом удаленной отладки JDWP. Приложение принимает на указанный порт подключения отладчика. Это может быть отдельная утилита jdb, или встроенная в IDE.

В JDK поставляется набор инструментов для мониторинга. Например Java Mission Control и JConsole позволяют подключиться к приложению и посмотреть множество показателей его здоровья. Полный список инструментов специфичен для конкретной JVM, для HotSpot можно посмотреть в документации.

Вне зависимости от обстоятельств, всегда необходимо заранее позаботиться о диагностической информации номер один – логах. Как минимум, ни один встроенный инструмент не покажет вам информацию о событиях, определяемых бизнес-логикой вашего приложения. Логироваться должен необходимый минимум, который позволит при любом инциденте понять, что произошло.

В стандартную поставку Java включен пакет для логгирования java.util.logging, позже остановимся на нём подробнее. Также существует ряд популярных библиотек: Log4j, SLF4J, Logback. Про техники и сложности логгирования современного энтерпрайза есть неплохой доклад.

👉@BookJava

Бывают ли в Java утечки памяти?


Сначала стоит сказать, что это такое. Утечка памяти (memory leak) в широком смысле – потеря доступа к некоторой сущности, которая при этом всё еще остается «живой» и расходует ресурсы компьютера.

Основное отличие Java от языков вроде C – автоматическое управление памятью. В общем случае вам не нужно думать об удалении объекта из памяти. Когда он перестал быть нужен, сборщик мусора сделает это за вас.

Но всё-таки бывают случаи, когда JVM не способна помочь, и прибираться за собой нужно вручную:

1. Объекты в статических полях. Обычно они живут пока живёт класслоадер, который обычно живет до конца работы приложения. В эту же группу риска попадают синглтоны, которые обычно базируются на статиках. Отдельного внимания заслуживает случай утечки ThreadLocal.

2. Взаимодействие с нативным кодом и ручное управление памятью. Когда вы решаетесь на ручное/внешнее управление, вся ответственность за сборку мусора переходит на вас. Это касается использования Unsafe и нативных библиотек. Сюда же попадают различные утечки внешних ресурсов: например соединений с базой через нативный драйвер.

3. Неправильное использование коллекций. Несогласованность методов equals-hashCode может позволить ключам теряться внутри HashMap/HashSet. Размер зарезервированной памяти часто не совпадает с размером содержимого: тот же HashMap, однажды раздувшись, не умеет уменьшаться.
4. Использование finalize. Вмешиваясь в нормальную работу GC, вы, естественно, можете её нарушить. Поток финализации имеет низкий приоритет – даже корректная реализация метода может не успеть выполниться и привести к OutOfMemoryError.

5. Утечка inner-класса. В отличие от nested, inner класс содержит неявную ссылку на своего хозяина. Так что экземпляр хозяина гарантированно будет жить пока живут экземпляры его inner-классов.

6. Интернированные строки. Вызовом String.intern() вы подписываетесь под тем, что осознаете что делаете. Ручное использование оптимизационных хитростей JVM не может не сопровождаться риском. Поведение этого метода зависит от версии Java и реализации JVM.

7. Паттерн Flyweight/object pool. И пул строк, и вся модель памяти реализуют его. Неправильная программная реализация паттерна также может привести к утечке объектов – зависанию их в пулле без реальных применений снаружи.

8. Всевозможные логические утечки. Нарушение консистентности модели бизнес-данных может приводить к забытым объектам. Технически это всё еще один из пунктов выше. Типичный пример такой утечки – утечка Activity в Android.

Так что ответ на вопрос – редко, но бывают.


👉@BookJava