Java Portal | Программирование
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
Показати більше📈 Аналітичний огляд Telegram-каналу Java Portal | Программирование
Канал Java Portal | Программирование (@java_iibrary) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 11 910 підписників, посідаючи 10 465 місце в категорії Технології та додатки та 53 914 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 11 910 підписників.
За останніми даними від 30 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 290, а за останні 24 години на -1, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 10.90%. Протягом перших 24 годин після публікації контент зазвичай збирає 6.28% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 1 299 переглядів. Протягом першої доби публікація в середньому набирає 748 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 3.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як boot, string, void, архитектура, resttemplate.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
Завдяки високій частоті оновлень (останні дані отримано 31 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
До 8 сентября действует скидка 25% -- тык
Future и CompletableFuture в Java?
Обычно на это отвечают размыто. Давай разложим по полочкам.
Что такое Future
• Появился в Java 5 вместе с Executor framework.
• Представляет результат асинхронного вычисления.
• Обычно ты отдаешь Callable в ExecutorService, который возвращает Future<T>.
С ним можно:
• вызвать get() → блокирует поток, пока задача не завершится
• вызвать isDone() → проверить, закончилась ли задача
• вызвать cancel() → попытаться отменить выполнение
И на этом все. Future дает контроль над ожиданием, но никак не управляет тем, что делать, когда результат готов.
Что добавляет CompletableFuture
• Появился в Java 8, реализует Future и CompletionStage.
• Все еще является Future (можно блокироваться, если хочется), но гораздо функциональнее.
• Поддерживает неблокирующие коллбеки (thenApply, thenAccept, thenRun).
• Позволяет комбинировать задачи (thenCombine, allOf, anyOf).
• Умеет завершаться вручную через complete(), чего у Future нет.
• Даёт более гибкую обработку ошибок (exceptionally, handle).
Главная разница
С Future ты просто ждешь результат. С CompletableFuture ты описываешь, что должно произойти, когда результат появится.
👉 Java Portalclass UserDTO {
private String name;
private String email;
}
2. ModelMapper
ModelMapper это библиотека для автоматического маппинга DTO <-> Entity.
Без него пришлось бы вручную писать:
dto.setName(entity.getName());
dto.setEmail(entity.getEmail());
С ModelMapper это превращается в:
UserDTO dto = modelMapper.map(userEntity, UserDTO.class);
Плюсы: меньше шаблонного кода.
Минусы: для сложных кейсов нужна настройка, а ещё можно легко пропустить баг в маппинге, если полагаться только на автоматику.
3. Jackson
Jackson это библиотека, которую Spring Boot использует для (де)сериализации JSON.
Что делает:
- Превращает Java-объекты в JSON (ответ API).
- Превращает JSON в Java-объекты (тело запроса).
Пример:
{ "name": "Sumit", "email": "sumit@email.com" }
автоматически маппится в UserDTO в контроллере.
Как они работают вместе:
- Jackson: JSON <-> DTO
- ModelMapper: DTO <-> Entity
- DTO: слой-контракт между внешними клиентами и внутренними моделями
DTO защищает доменную модель, Jackson работает с JSON, а ModelMapper убирает рутину маппинга.
👉 Java PortalDataSource, JdbcTemplate, EntityManagerFactory и т.д.
Когда баз становится две, фреймворк не понимает, какую взять за основную. Автоконфигурация перестаёт работать, и нужно явно объявить бины для каждой, одну пометить как @Primary. А дальше подключать их через @Qualifier там, где требуется. ✏️
У кого так было? 👍
👉 Java Portal• Задержки + глобальная аудитория → CDN. Доставляем данные с edge-серверов, чтобы уменьшить latency. • Чтение + узкое место → кэш. Часто читаемые данные кладём в кэш, разгружая базу. • Запись + всплеск трафика → очередь. Пишем асинхронно, сглаживая пики нагрузки. • Распределённая транзакция → Saga. Координируем шаги с компенсациями между сервисами. • ACID + реляционка → SQL. Строгая консистентность и транзакции. • Гибкость + масштаб → NoSQL. Подходит для схемы без фиксированной структуры и горизонтального масштабирования. • SQL + рост → шардинг. Делим базу на шарды, чтобы тянуть нагрузку. • Нагрузка + рост → scale out. Добавляем сервера, а не апгрейдим один. • Трафик + надёжность → балансировка. Распределяем запросы для стабильности. • Критичные сервисы + отказ → резервирование. Дублируем, чтобы не было single point of failure. • Долговечность + сбои → репликация. Держим копии данных для доступности и восстановления. • Запросы + всплески → троттлинг. Ограничиваем лишние запросы. • Нагрузка + пики → автоскейлинг. Автоматически подгоняем мощность под трафик. • Реалтайм + обновления → WebSockets. Двунаправленное живое соединение. • Повтор + безопасность → идемпотентность. Повторяем операции без побочных эффектов.👉 Java Portal
if для компонентов. Так можно сделать приложение гибким -> включать и отключать фичи или менять поведение через конфиг или зависимости проекта, не меняя Java-код.
Для этого используют аннотации, начинающиеся с @Conditional, которые ставят на методы с @Bean или на классы с @Component. Если условие выполнено, Spring создаёт бин. Если нет, то бин игнорируется.
Примеры часто используемых аннотаций:
@ConditionalOnProperty проверяет, есть ли у свойства в application.properties заданное значение. Это основной способ для feature toggling.
@ConditionalOnClass проверяет, есть ли определённый класс в classpath. Удобно, если нужно создавать бин только при наличии библиотеки.
@ConditionalOnMissingBean создаёт бин, только если нет другого бина такого же типа. Подходит для дефолтных или fallback-компонентов.
@ConditionalOnWebApplication создаёт бин только если приложение работает как веб-приложение, например под Tomcat.
👉 Java Portalfinally выполняется всегда, при любых обстоятельствах. Но так ли это на самом деле?
Можешь назвать ситуацию, когда он не сработает?
Ответ — нет, но с важной оговоркой.
Фатальный краш JVM (например, StackOverflowError) это стопроцентный «нет» для finally.
А вот с System.exit() всё интереснее. Если вызов проходит успешно, JVM завершается сразу, и finally пропускается. Если же SecurityManager блокирует вызов, выбрасывается SecurityException, и блок finally выполняется в рамках обычной обработки ошибки.
То есть поведение реально зависит от прав, заданных в рантайме.
👉 Java Portal hashCode(), чтобы определить, в какой бакет попадёт ключ.
Внутри бакета вызывается equals(), чтобы проверить, есть ли уже такой ключ.
Если переопределить только equals(), но оставить дефолтный hashCode() (по адресу в памяти), получится проблема. Два объекта, которые равны по equals(), могут иметь разные хэши. Тогда они попадут в разные бакеты, и HashMap воспримет их как разные ключи.
Итог: поиск по ключу может “ломаться”, значения будут “теряться”, а одинаковые по смыслу ключи могут храниться дублирующимися.
Поэтому существует контракт: если объекты равны по equals(), они обязаны возвращать одинаковый hashCode(). В противном случае любые коллекции на основе хэшей (HashMap, HashSet, Hashtable) будут вести себя неправильно.
👉 Вывод прост. Всегда переопределяй equals() и hashCode() вместе.
👉 Java Portal