Java Portal | Программирование

«В Algorithms Illuminated Тим Раффгарден объясняет основы алгоритмов максимально доступным способом.» – https://algorithmsilluminated.org От умножения целых чисел до NP-полноты — 4 части, 100+ видео, каждое синхронизировано с разделами книги для глубокого погружения. 👉 Java Portal

Если HashMap позволяет null, почему ConcurrentHashMap при тех же операциях кидает NullPointerException? В HashMap можно хранить один ключ null и любое количество значений null. В ConcurrentHashMap любое использование null (ключ или значение) вызывает NullPointerException. Разница здесь в ясности и безопасности работы в многопоточной среде. В однопоточном HashMap, если map.get(k) возвращает null, можно уточнить через map.containsKey(k). Этот двухшаговый подход работает, потому что между вызовами никто не меняет карту. В многопоточном окружении такой трюк ломается. Поток A может вызвать containsKey(k) и увидеть ключ. До того как он вызовет get(k), поток B может удалить эту запись. Теперь get(k) вернёт null, и поток A не сможет понять, было ли значение реально null или запись исчезла между вызовами. Двухшаговая проверка не атомарна и ненадёжна. Атомарные методы вроде putIfAbsent, computeIfAbsent и replace тоже используют null как “отсутствие отображения”. Если бы null был допустимым значением, эти методы становились бы неоднозначными или требовали бы обёрток и дополнительных проверок, усложняя API и реализацию. Запрещая null в ключах и значениях, ConcurrentHashMap гарантирует, что get(k) == null всегда и однозначно означает “нет отображения”. Это упрощает API, делает семантику ясной и позволяет эффективно работать в многопоточном режиме. 👉 Java Portal

Сегодня отмечается День программиста! 256-й день года выбран не случайно:

Дата праздника объясняется расчетом: 2 (двоичная система исчисления) в степени 8 (количество битов в байте). То есть 2^8= 256. Поэтому в обычный год день программиста 13 сентября, а в високосный — 12 сентября

С праздником, коллеги! ☺️ @IT_Portal

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

VK JT = Java + Go! 16 сентября VK приглашает Go‑ и Java‑разработчиков на VK JT Meetup в Санкт-Петербурге. В программе: — Максимально практические доклады от техлидов VK о трансформации ВКонтакте, переходе части сервисов на Go и об устройстве и развитии единой видеоплатформы VK — Командные бэкенд-баттлы под менторством опытных разработчиков VK — кейсы, вдохновлённые реальной архитектурой VK Задавайте вопросы экспертам, ищите лучшее командное решение кейса и оставайтесь на афтепати: нетворкинг, фуршет, свободное общение с коллегами. Только офлайн, в офисе VK на Мойке. 🎟 Участие бесплатное, почитать подробнее и зарегистрироваться вы сможете на сайте

Если бы ты разрабатывал API, как бы ты дал клиентам выбор между синхронными и асинхронными вызовами, не дублируя одну и ту же логику дважды? Многие разработчики попадают в ловушку дублирования методов -> один для синхронного использования, другой для асинхронного. На первый взгляд это кажется нормальным, но на деле удваивает работу по поддержке и может привести к скрытым багам, если один из путей обновить, а другой забыть. Более умный подход заключается в том, чтобы один раз спроектировать основную логику и дать клиентам самим выбрать, как её использовать. Самый простой паттерн заключается в том, чтобы сделать асинхронную версию основным методом. Она может возвращать CompletableFuture или реактивный тип вроде Mono в Spring. Клиенты, которым нужен асинхронный вызов, используют его напрямую. Клиенты, которым нужен синхронный вариант, просто вызывают .join() или .get(). Таким образом, у тебя есть только один кодовый путь для поддержки. Асинхронные клиенты получают неблокирующую производительность, синхронные получают удобство блокирующих вызовов, а API остаётся чистым и устойчивым к будущим изменениям. 👉 Золотое правило здесь -> логику пишем один раз, используем её двумя способами. 👉 Java Portal

Готовим себя к собеседованиям в FAANG как в настоящем университете I. Структуры данных, алгоритмы и классические вопросы II. Упор на Python, Java, C++, C, но есть и материалы по Go, JS, Rust, Ruby III. Примеры задач с разбором оптимизаций IV. Подготовка не только к техническим этапам, но и к общим/поведенческим интервью Репозиторий настолько топовый, что его отметили даже разработчики из Google. И да, есть перевод на русский. 💯 https://github.com/jwasham/coding-interview-university 👉 Java Portal

Ты на интервью по системному дизайну. Спрашивают: «Как бы ты спроектировал слой кэширования для высоконагруженного веб-приложения?» Вот подробный подход: I. Что кэшировать → Кэшируй дорогие запросы к БД, горячие данные с большим количеством чтений и статические ресурсы; избегай очень динамичных, гигантских объектов или чувствительной PII, если только она не зашифрована и не защищена доступом. II. Хранилище кэша → Используй Redis или Memcached для распределённого in-memory кэша, CDN для статики на краю сети, локальные in-process кэши (например, Caffeine) для сверхнизкой задержки L1. III. Паттерн и запись → По умолчанию Cache-Aside: читаем из кэша, при промахе читаем из БД и заполняем кэш. Для сильной консистентности чтения — Write-Through (пишем одновременно в кэш и БД). Всегда сначала коммитим БД, потом обновляем/инвалидируем кэш, чтобы не дать устаревшим данным просочиться. IV. Истечение и вытеснение → TTL для каждого типа данных, чтобы держать кэш свежим, политики вытеснения (LRU/LFU) для управления памятью, negative caching для промахов, чтобы не перегружать БД. Ограничивай размер объектов, чтобы не создавать проблемы с памятью и сборкой мусора. V. Масштабирование и «горячие ключи» → Масштабируй через consistent hashing и реплики для пропускной способности чтения. Многоуровневый кэш (edge→regional→local). Горячие ключи — локальные L1 кэши, отдельные кэши для горячих ключей, либо rate-limiting запросов. VI. Надёжность и наблюдаемость → Предотвращай «каскады» промахов через request coalescing, короткие блокировки (SETNX + expiry) или serve-stale-while-revalidate с jittered TTL. Мониторь hit rate, latency, eviction, память и replication lag с алертами. 👉 Java Portal

Выбор структуры данных I. Быстрый поиск → HashMap II. Отсортированный порядок → Сбалансированное BST (AVL, Красно-Чёрное дерево) III. FIFO / LIFO → Очередь / Стек IV. Поиск по префиксу → Trie V. Связность → Union-Find VI. Запросы по диапазону → Segment Tree VII. Медиана потока → Две кучи (Two Heaps) VIII. Скользящее окно → Deque IX. Вытеснение кэша → LRU Cache 👉 Java Portal

Задумывались ли вы, что поддерживает приложение Spring Boot в живом состоянии и работоспособном? ❔ Это ApplicationContext, настоящее сердце Spring Boot. Объясняю проще: В Spring Boot ApplicationContext это центральный контейнер времени выполнения, который управляет компонентами вашего приложения, называемыми beans (бинами). Он отвечает за загрузку конфигураций, создание и связывание бинов, управление их жизненным циклом и предоставляет такие сервисы, как загрузка ресурсов, интернационализация, доступ к окружению/профилям и публикация событий приложения. Когда контекст обновляется (например, при старте приложения), он читает источники конфигурации (аннотации, свойства, XML и автоконфигурацию), регистрирует BeanPostProcessors и BeanFactoryPostProcessors, и по умолчанию заранее создаёт синглтон-бины, чтобы они были готовы к использованию. Обычно вы взаимодействуете с бинами через dependency injection, а не через их поиск, но вы можете получить бин программно с помощью getBean Spring Boot строится поверх Spring, используя ApplicationContext для регистрации и конфигурации авто-конфигурируемых бинов, что позволяет использовать конвенции "из коробки". ConfigurableApplicationContext предоставляет операции жизненного цикла, такие как refresh() и close(), а также публикует события жизненного цикла, такие как ContextRefreshedEvent Существуют различные реализации ApplicationContext для разных случаев использования, например, AnnotationConfigApplicationContext для Java-конфигурации и WebApplicationContext для веб-приложений. Вкратце, ApplicationContext это сердце Spring Boot, потому что многое из поведения фреймворка, включая управление бинами, конфигурацию и точки интеграции, организовано и обслуживается через него. Он поддерживает иерархии контекстов для изоляции в модульных приложениях и обеспечивает надёжное разрешение ресурсов. 👉 Java Portal

Почему логи уже не спасают в мире микросервисов Когда один запрос может пролетать через 10+ сервисов, по логам не всегда поймёшь, где именно произошёл затык или фейл. Тут на сцену выходит OpenTelemetry — современный cloud-native стандарт для распределённого трейсинга. Он умеет работать с Jaeger, Tempo, Zipkin, Prometheus, Grafana и собирает не только трейсинг, но ещё и метрики с логами — всё в одном месте. Логи отвечают на вопрос что произошло. Трейсы показывают где это произошло. А ты уже внедрял OpenTelemetry в свои сервисы? 🍺 👉 Java Portal

Почему устойчивые микросервисы продолжают работать даже когда их зависимости рушатся? У них есть общий приём Circuit Breaker и в Spring Boot это делается довольно просто. В распределённых системах отказы обычное дело базы могут подвисать, API уходить в таймауты, сеть лагать. Без защиты такие сбои начинают цепной реакцией сжирать потоки и валить сервис. Circuit Breaker решает проблему когда количество ошибок превышает порог он размыкается и быстро возвращает фолбэк вместо того чтобы долбиться в нерабочий ресурс. В Spring Boot для этого используют лёгкую и современную библиотеку Resilience4j. Там настраиваются порог ошибок, время ожидания и правила восстановления. Как только выключатель уходит в open все запросы режутся. По истечении тайм аута он переключается в half open и пропускает несколько тестовых вызовов. Если они проходят успешно, схема снова закрывается и трафик идёт как обычно. Если нет возвращается в open. В итоге сервис остаётся отзывчивым даже если его зависимости лежат. В паре с таймаутами, ретраями и bulkhead изоляцией, это превращается в полноценный набор для отказоустойчивости. Польза очевидна, вместо падения всей системы - аккуратная деградация и стабильность, что и отличает продакшен уровень. 👉 Java Portal

«Что такое CAP-теорема и почему она важна в распределённых системах?» CAP-теорема утверждает, что в распределённой базе данных одновременно можно гарантировать только два свойства из трёх - Consistency, Availability и Partition Tolerance. Так как сетевые разделения неизбежны, приходится выбирать между консистентностью и доступностью. Consistency означает, что каждое чтение возвращает самую последнюю запись, независимо от того, на какой реплике выполняется запрос. Для сильной консистентности обычно требуется координация между узлами перед тем, как подтвердить ответ. Availability означает, что каждый запрос получает ответ, даже если это не самые свежие данные. Система остаётся доступной и отвечает на запросы, несмотря на сбои отдельных узлов. Partition Tolerance означает, что система продолжает работать даже при сетевых разрывах или потере сообщений. В реальности разделения всегда происходят, поэтому это свойство нельзя исключить. Так как P всегда должно выполняться, в реальных системах приходится выбирать между CP и AP. CP-системы отдают приоритет консистентности и устойчивости к разделению, жертвуя доступностью во время сбоев. Примеры — ZooKeeper, Google Spanner, CockroachDB. AP-системы делают ставку на доступность и устойчивость к разделению, во время проблем могут отдавать устаревшие или несовпадающие данные, но со временем данные приходят к единому состоянию. Примеры — Cassandra, Riak, DynamoDB. CP имеет смысл для финансовых и критически важных приложений, где важна корректность данных. AP лучше подходит для масштабных систем, где приоритет — чтобы сервис всегда отвечал, даже ценой временной рассогласованности. Многие современные базы позволяют настраивать уровень консистентности под конкретные задачи. 👉 Java Portal

⚡️ Айтишник из «VISION» скупил топовые айти-курсы и выложил гигабайты материалов к себе Каждый найдет что-то по душе: 1202 ГБ — Python 1811 ГБ — Frontend 1100 ГБ — C / C++ / C# 804 ГБ — Java 411 ГБ — SQL & БД 309 ГБ — DevOps 998 ГБ — ИБ & Хакинг 773 ГБ — Kotlin / Swift 189 ГБ — PHP 201 ГБ — GoLang 170 ГБ — Rust 167 ГБ — QA / Тестирование 310 ГБ — 1C + Лицензии 495 ГБ — Машинное обучение 704 ГБ — Аналитика Данных 991 ГБ — Дизайн Материалы в закрепе, постоянно пополняются👆🏻

Самые ходовые аннотации в Spring Boot Если ты работал со Spring Boot, то наверняка встречал эти теги на каждом шагу. Вот топ-10: I) @SpringBootApplication II) @RestController III) @RequestMapping / @GetMapping / @PostMapping IV) @Autowired V) @Component VI) @Service VII) @Repository VIII) @Configuration IX) @Bean X) @Value ❓ Сколько из них ты реально использовал в продакшн-коде? 👉 Java Portal

Ты тоже путаешься в этих двух терминах Reverse Proxy и Load Balancer, давай разберёмся Reverse proxy ставится перед твоими серверными приложениями и проксирует к ним клиентские запросы, его задачи не ограничиваются распределением трафика, он также может делать SSL termination и обрабатывать HTTPS, выполнять аутентификацию и авторизацию, кэшировать ответы, скрывать внутренние детали инфраструктуры, трансформировать запросы и ответы. Примеры NGINX, Apache, HAProxy Load balancer это частный случай reverse proxy, но с более узкой задачей, распределять входящий трафик между несколькими серверами, он сфокусирован на производительности и доступности, балансировщик следит чтобы ни один сервер не был перегружен и берёт на себя фейловер если один из них отваливается. Примеры HAProxy, AWS ELB, F5 Разница в том что reverse proxy умеет много всего, безопасность, кэширование, роутинг, а load balancer в основном занимается только распределением трафика между серверами. Коротко, все load balancer являются reverse proxy, но не все reverse proxy это load balancer 👉 Java Portal

С виду простой парень На деле — Стив Джобс в мире отношений. В личке у него очередь из пацанов, которые с его помощью нашли любовь всей жизни, а десятки семейных пар перестали ругаться из-за мелочей. Сейчас Иван Абсент ведет свой блог и остается одним из немногих, кто без пикап-тренингов и токсичных советов может объяснить даже подростку, как выстроить гармоничные отношения и перестать бояться знакомств. Внутри он на недушном языке объясняет: • как перестать быть «другом» и стать мужчиной мечты, • как вернуть искру в долгие отношения, • почему первые 5 секунд с девушкой — решающие. Подписывайтесь, потом сами себе спасибо скажете: https://t.me/+MEMyK2t3Ajw4OGFi

Твой запрос не попадает напрямую в контроллер. Он проходит через цепочку фильтров — Filter Chain. Это основа Spring Security. Когда HTTP-запрос попадает в Java-приложение, он никогда не идет напрямую в контроллер. Сначала он проходит через Filter Chain — упорядоченную последовательность фильтров, которые могут проверить, изменить или заблокировать запрос до того, как выполнится твой код. Эта идея пришла из Servlet API. Фильтр реализует метод doFilter(request, response, chain). Внутри можно сделать предобработку (например, логирование или проверку заголовков), вызвать chain.doFilter(request, response), чтобы передать запрос дальше, или прервать выполнение, фактически заблокировав запрос (например, вернув 403 Forbidden). Spring Security расширяет это через FilterChainProxy, который управляет одним или несколькими SecurityFilterChains. Каждая цепочка применяется к своим URL-паттернам и содержит строго упорядоченный набор фильтров. Примеры: • Аутентификационные фильтры (например, UsernamePasswordAuthenticationFilter или кастомный JWT-фильтр) определяют личность пользователя. • Фильтр авторизации проверяет права и роли. • Фильтр управления сессией отвечает за логин-сессии. • CSRF-фильтр защищает от подделки запросов. • Фильтр перевода исключений гарантирует, что ошибки безопасности вернут правильный ответ. Порядок имеет значение: аутентификация должна происходить раньше авторизации, CSRF-проверка — до обработки запроса, а обработка исключений должна оборачивать всю цепочку. Поэтому Spring предоставляет методы addFilterBefore и addFilterAfter для кастомизации. Только после прохождения всех нужных проверок запрос попадает в контроллер. Простой поток: Request → Filter Chain → Controller → Response → Filter Chain → Client 👉 Java Portal

Stateful vs Stateless дизайн Stateless-дизайн сделал возможным простые, но при этом масштабируемые и быстрые приложения. Вместо хранения состояния в памяти сервера, каждый запрос несет все данные для своей обработки. Это убрало лишние накладные расходы и позволило легко масштабировать системы. Stateful-приложения работают иначе. Они хранят данные вроде user ID, сессий и настроек, что дает персонализацию и избавляет от передачи повторяющейся информации. Но из-за этого тяжело масштабироваться горизонтально. Stateless-подход стал основой для микросервисов, serverless и REST API. Он ускоряет работу CDN и повышает эффективность сервисов. Но у него есть минусы - - большие размеры запросов, избыточная передача данных и сложности в сценариях, где состояние критично. На практике чаще выбирают гибрид — сочетание stateful и stateless. Баланс позволяет сделать систему масштабируемой, простой и быстрой, не жертвуя функциональностью 💪 👉 Java Portal

Аннотация @Transactional не работает, когда ты вызываешь метод из другого метода в том же классе? Это не баг, а классическая особенность Spring AOP по дизайну. Знаешь, почему транзакция вообще не стартует? Проблема в том, как Spring AOP создаёт прокси. Когда ты ставишь @Transactional на метод, Spring не правит байткод класса. Вместо этого он создаёт прокси-объект, который оборачивает твой бин. Этот прокси перехватывает внешние вызовы метода, запускает транзакцию и потом делегирует вызов реальному методу бина. Это отлично работает, когда внешний бин вызывает твой публичный транзакционный метод, потому что вызов проходит через прокси. Но при самовызове внутри класса (например, this.someTransactionalMethod()) ты вызываешь метод напрямую на целевом объекте (this), а не через прокси. Транзакционный advice прокси полностью обходится, поэтому транзакция не стартует. Это фундаментальное следствие прокси-based AOP. Чтобы исправить, самое чистое и продакшен-готовое решение это вынести транзакционный метод в отдельный Spring-бин и инжектить его. Тогда вызов всегда будет внешним и пройдёт через прокси, корректно поднимая транзакцию каждый раз. 🙈 👉 Java Portal