Используйте Stream.peek() только для отладки, а не для реальной логики.

✅ peek() выполняется как побочный эффект, поэтому его вызов легко не заметить или вообще потерять при выполнении Stream pipeline.
✅ Для намеренной обработки данных лучше использовать map() или forEach().

#Java #Streams

👉 Java Portal

Флаг Java, который снижает потребление памяти без единого изменения в коде.

Compact Object Headers уменьшают размер заголовка каждого объекта с 16 до 8 байт на 64-битных архитектурах.
В одном из сценариев бенчмарка SPECjbb2015 в JEP указывается снижение использования heap на 22% и CPU на 8% — OpenJDK, JEP 519.

Более того, согласно JEP 534, Amazon уже использует эту возможность в продакшене в сотнях сервисов, причём большинство из них работает на бэкпортах для Java 17 и 21.

В JDK 25 эту опцию нужно включать вручную:
-XX:+UseCompactObjectHeaders

Но есть важный момент: JEP 534 предлагает сделать Compact Object Headers поведением по умолчанию в JDK 27.

👉 Java Portal

В Spring Boot 4 больше нет @MockBean — вместо него теперь используется @MockitoBean.
Для моков в полях всё привычно:

— @MockitoBean
— @MockitoSpyBean

Но в классах @Configuration они больше не используются. Для общих моков теперь рекомендуется подключать тестовые конфигурации через @Import.

#SpringBoot4 #Testing

👉 Java Portal

Тяжело нынче быть Java-разработчиком...

👉 Java Portal

Сохрани этот ресурс, если работаешь с SQL.

Это playground без установки, где можно:

- создавать таблицы, выполнять запросы и делиться результатами;
- работать с MySQL, PostgreSQL и SQL Server.

Бесплатно и без установки:
→ http://runsql.com/r

👉 Java Portal

В Spring Boot 4 библиотекой для работы с JSON по умолчанию стала Jackson 3.

✅ Изменились пакеты: com.fasterxml → tools.jackson
✅ Вместо обычного изменяемого бина ObjectMapper используется неизменяемый JsonMapper, создаваемый через Builder
✅ Крайний вариант (устаревший): добавить spring-boot-jackson2

#SpringBoot4 #Jackson3

👉 Java Portal

Автор pgrust — PostgreSQL, переписанного на Rust, — рассказал о четырёх распространённых причинах сбоев PostgreSQL:

1. VACUUM и переполнение счётчика идентификаторов транзакций
2. Лимиты подключений и модель «один процесс на подключение»
3. Неудачные планы выполнения запросов — интересно, насколько здесь помогут новые хинты для запросов в PostgreSQL 19
4. Статистика для JSON

Раздел о JSON оказался интересным. Любопытно, устраняют ли расширения PostgreSQL вроде DocumentDB некоторые из этих ограничений.

Стоит прочитать, если вы работаете с PostgreSQL.

https://malisper.me/the-four-horsemen-behind-thousands-of-postgres-outages/

👉 Java Portal

Используйте Files.isSameFile(path1, path2), чтобы проверить, указывают ли два пути на один и тот же файл. Метод также учитывает симлинки.

✅ Он проверяет, ссылаются ли два объекта Path на один и тот же реальный файл в файловой системе.

#Java #JavaDev

👉 Java Portal

Кэшировать или не кэшировать?

Это вопрос, с которым бэкендер сталкивается каждый день.

Большинство инженеров кэшируют слишком много.
Это ленивая инженерия.

Вот небольшой фреймворк, чтобы принимать решение правильно:

I. Данные часто запрашиваются?
II. Их дорого получать?
III. Они изменчивые?
IV. Объём данных большой?
V. Влияет ли это на воспринимаемую пользователем задержку?
VI. Безопасно ли кэшировать?
VII. Есть ли механизм протухания или инвалидации кэша?

👉 Java Portal

Клиентское кэширование в HTTP работает так

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

Когда клиент впервые делает GET-запрос к ресурсу, локальный кэш проверяет его наличие. Если ресурса нет, запрос уходит на сервер. Сервер в ответе указывает, что данные можно закэшировать -> заголовок Cache-Control задаёт время жизни ресурса, а ETag определяет его конкретную версию. Кэш сохраняет ответ и возвращает его клиенту.

При повторном запросе, если ресурс ещё актуален, кэш сразу отдаёт его клиенту, минуя сервер. Однако сервер может обновить ресурс до истечения срока жизни в кеше, поэтому данные в кеше и на сервере не всегда строго согласованы. Обычно это приемлемо, а чтобы гарантировать обновление, сервер просто меняет версию ресурса.

Если ресурс в кеше устарел, кэш отправляет новый запрос на сервер с условным заголовком, например If-None-Match, где указывает сохранённую версию. Если сервер имеет новую версию, он возвращает её. Если изменений не было, он отвечает кодом 304 Not Modified, и клиент продолжает использовать локальные данные.

👉 Java Portal

Используйте ReentrantReadWriteLock, когда операций чтения много, а записи происходят редко.

✅ Несколько потоков могут одновременно удерживать блокировку чтения
✅ Для записи требуется эксклюзивная блокировка
✅ При преобладании чтения пропускная способность выше, чем с одной эксклюзивной блокировкой

#Java #Concurrency

👉 Java Portal

Большинство проблем с производительностью упираются в то, как вы работаете с памятью.

И эта статья до сих пор остаётся одним из лучших материалов по теме:

• Как на самом деле работает оперативная память
• Кеши процессора и почему от них так сильно зависит производительность
• Практические методы оптимизации
• Инструменты для измерения того, что реально происходит в системе

Автор — Ульрих Дреппер из Red Hat.

Материалу почти 20 лет, но он до сих пор актуален.

Доступно бесплатно:

https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

👉 Java Portal

💡 В Spring Boot 4 изменилось имя настройки, отвечающей за включение трассировки.

✅ management.tracing.enabled → management.tracing.export.enabled
✅ @ConditionalOnEnabledTracing → @ConditionalOnEnabledTracingExport

#SpringBoot4 #Observability

👉 Java Portal

Если вы присваиваете переменной значение, полученное из её текущего значения с применением арифметической операции, можно использовать оператор составного присваивания.

Подробнее об операторе составного присваивания: https://social.ora.cl/6018BDGLH0

👉 Java Portal

Хотите разобраться в алгоритмах поиска и сортировки на Java?

Этот подробный курс научит эффективно искать данные и сортировать массивы с помощью самых важных алгоритмов информатики.

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

https://social.ora.cl/6011BEIoOf

👉 Java Portal

Spring Boot 4: чтобы перенести ключи конфигурации, временно используйте properties-migrator как помощник.

✅ При запуске и в логах он показывает, какие ключи устарели.
✅ Обновите ключи, затем удалите зависимость.

#SpringBoot4 #Migration

👉 Java Portal

MIT 6.824 (распределённые системы) — один из лучших бесплатных инженерных курсов в интернете.

Вместо чистой теории весь курс построен вокруг чтения и разбора фундаментальных работ из реальных систем:

GFS (Google File System) — архитектура с одним главным узлом, распределение чанков и работа с eventual consistency при больших нагрузках на добавление данных.

Raft — выбор лидера, репликация журнала и инварианты безопасности. Алгоритм разбирается намного доступнее, чем Paxos.

ZooKeeper — координация без блокировок, системы с преобладанием чтения, линейно согласованные записи и eventual consistency для чтений через watches.

Spanner — глобально распределённые транзакции, двухфазный commit поверх Paxos и использование TrueTime (атомные часы + GPS) для обеспечения внешней согласованности.

Также в курсе разбираются MapReduce, Spark, Frangipani, Memcached от Facebook и другие системы.

Если хотите выйти за пределы поверхностного system design и понять, как внутри устроены реальные распределённые хранилища и системы консенсуса, этот курс — настоящий клад.

Плейлист: https://youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB

👉 Java Portal

Используйте Files.isSameFile(a, b), чтобы проверить, указывают ли два пути на один и тот же файл.

✅ Path.equals сравнивает только текстовое представление пути.
✅ isSameFile проверяет реальный файл и учитывает симлинки.

#Java #Files

👉 Java Portal

В Spring Boot 4 больше нет поддержки Undertow — теперь рекомендуется использовать Tomcat или Jetty.

Что изменилось:

* Undertow несовместим с Servlet 6.1.
* Вместо starter-undertow используйте Tomcat (по умолчанию) или Jetty.
* Не разворачивайте приложения на Spring Boot 4 в старых сервлет-контейнерах.

👉 Java Portal

Лучшие инженеры не изучают распределённые системы по поверхностным пересказам. Они сразу обращаются к фундаментальным научным статьям. Чтение таких работ помогает понять, почему системы спроектированы именно так, а не просто научиться ими пользоваться.

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

1. The Google File System (2003)

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

Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf

2. Dynamo: Amazon’s Highly Available Key-Value Store (2007)

Почему стоит прочитать: исчерпывающий разбор того, как пожертвовать согласованностью ради высокой доступности — AP в теореме CAP. В статье изложены ключевые паттерны, лежащие в основе масштабируемых NoSQL-хранилищ: консистентное хеширование, векторные часы, gossip-протоколы и настраиваемый кворум для операций чтения и записи.

Ссылка: https://allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

3. In Search of an Understandable Consensus Algorithm (Raft) (2014)

Почему стоит прочитать: Paxos печально известен тем, насколько сложно его понять и корректно реализовать, тогда как Raft делает концепцию реплицируемых конечных автоматов более доступной. Алгоритм разбивает задачу консенсуса на отдельные подзадачи, которые легко анализировать: выбор лидера, репликацию журнала и обеспечение безопасности.

Ссылка: https://raft.github.io/raft.pdf

4. Spanner: Google’s Globally-Distributed Database (2012)

Почему стоит прочитать: статья показывает, как добиться строгой сериализуемости и внешней согласованности между дата-центрами по всему миру. Секрет — API Google TrueTime, ограничивающий неопределённость времени с помощью синхронизированных GPS-приёмников и атомных часов.

Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

5. Time, Clocks, and the Ordering of Events in a Distributed System

Почему стоит прочитать: на физическое время нельзя полагаться при работе с независимыми узлами. Лэмпорт вводит логические часы и фундаментальное отношение «произошло до» (happened-before), лежащее в основе упорядочивания событий в современных распределённых сетях.

Ссылка: https://amturing.acm.org/p558-lamport.pdf

👉 Java Portal