Java Portal | Программирование
前往频道在 Telegram
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
显示更多📈 Telegram 频道 Java Portal | Программирование 的分析概览
频道 Java Portal | Программирование (@java_iibrary) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 12 130 名订阅者,在 技术与应用 类别中位列第 10 402,并在 俄罗斯 地区排名第 54 525 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 12 130 名订阅者。
根据 07 六月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 -138,过去 24 小时变化为 2,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 11.37%。内容发布后 24 小时内通常能获得 6.26% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 1 379 次浏览,首日通常累积 760 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 4。
- 主题关注点: 内容集中在 boot, string, void, архитектура, resttemplate 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
凭借高频更新(最新数据采集于 08 六月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
12 130
订阅者
+224 小时
-287 天
-13830 天
帖子存档
Spring Boot: на этапе разработки используй spring.main.lazy-initialization=true, чтобы ускорить старт приложения.
По умолчанию Spring Boot жадно инициализирует все бины на старте. В дев-окружении это значит:
1. Дольше стартует, особенно в больших проектах
2. Приходится ждать загрузки бинов, которые тебе прямо сейчас не нужны
Чтобы этого избежать, в
application.properties поставь:
spring.main.lazy-initialization=true
Но в проде важно оставить дефолтное поведение, потому что:
1. Ошибки старта ловятся раньше
2. Все компоненты сразу готовы принимать запросы
👉 Java PortalШпаргалка по разрядам чисел, максимальным и минимальным значениям
👉 Java Portal
👩💻 В сеть вывалилась гигантская куча курсов и книг
Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё!
• 1612 ГБ — DevOps
• 1402 ГБ — Python
• 1300 ГБ — C, C++
• 1815 ГБ — Frontend
• 1515 ГБ — Backend
• 898 ГБ — ИБ, Хакинг
• 996 ГБ — Kotlin, Swift
• 212 ГБ — JavaScript
• 315 ГБ — Flutter
• 820 ГБ — Go, PHP
• 419 ГБ — Java, Rust
• 648 ГБ — GameDev
• 517 ГБ — Windows, Linux
• 998 ГБ — Дизайн (UX/UI)
• 617 ГБ — Нейросети (ML/RL)
• 546 ГБ — БД (SQL & NoSQL)
• 687 ГБ — Аналитика данных
• 115 ГБ — QA-тестирование
Подписывайся и не плати за то, что можно получить бесплатно
Spring Boot: чтобы при сериализации в Jackson исключать любые поля, у которых значение null, можно использовать аннотацию
@JsonInclude(Include.NON_NULL)
@JsonInclude(JsonInclude.Include.NON_NULL)
public class UserDTO {
private Long id;
private String name;
private String email;
private String phone;
...
}
Все пустые поля исключаются автоматически.
👉 Java Portal🔴 Завтра тестовое собеседование с Java-разработчиком
21 января(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика.
Как это будет:
📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Сергею
Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.
Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot
Реклама.
О рекламодателе.
Spring Boot: используй CommandLineRunner, чтобы выполнять логику при старте приложения.
CommandLineRunner это интерфейс Spring Boot. Его можно реализовать, чтобы запускать код после того, как контекст приложения полностью инициализирован.
Некоторые сценарии, где это уместно:
Заполнение БД начальными данными
Запуск health-check’ов при старте
Бутстрап внешних сервисов/ресурсов
Пример:
@Component
public class StartupRunner implements CommandLineRunner {
@Override
public void run(String... args) {
System.out.println("Приложение запущено! Дальнейшая настройка");
}
}
👉 Java PortalПро модификаторы доступа в Java (public / default / protected / private)
private - только для себя
public - откуда угодно
protected - вроде бы для подклассов?
На самом деле тут всегда начинается каша, если не смотреть на вопрос "откуда и кто вызывает" по двум осям: пакет и наследование.
Чтобы нормально понять модификаторы, я подумал: пусть будет статья с моделью "якинику-ресторан".
Что такое модификаторы на самом деле:
Модификаторы - это не про "силу".
Это правила, откуда можно получить доступ.
В Java доступ всегда определяется двумя вещами:
* тот же пакет?
* есть наследование?
Модель с рестораном якинику:
* YakinikuShop: сам ресторан (родительский класс)
* LocalStaff: персонал этого же ресторана
* Manager: управляющий (дочерний класс)
* BranchStaff: персонал филиала (другой пакет + наследник)
* Customer: обычный клиент
Родительский класс: YakinikuShop.java
package shop;
public class YakinikuShop {
public int counter = 30; // Стойка/места: видно всем
int staffRoom = 10; // Комната персонала: только для своего пакета
protected int kitchen = 20; // Кухня: свой пакет или наследники
private int safeMoney = 100; // Сейф: даже управляющему напрямую нельзя
public void askManagerToOpenSafe(Object person) {
if (!(person instanceof Manager)) {
System.out.println("❌ Только управляющий может открыть сейф");
return;
}
openSafe();
}
private void openSafe() {
System.out.println("open safe: " + safeMoney);
}
}
Почему askManagerToOpenSafe "особенный"
askManagerToOpenSafe - public.
То есть вызвать его может кто угодно.
Но откроется сейф или нет - решает проверка instanceof внутри.
public != "можно всё"
public = "вход виден и доступен"
Суть public вот такая:
* ✅может вызвать клиент
* ✅может вызвать персонал
* ✅может вызвать кто-то из другого магазина
"Встать у входа и попросить" можно, но:
* ❌ если ты не управляющий - тебя сразу разворачивают
* ❌ private-сейф напрямую трогать нельзя
Таблица доступа:
Клиент:
public: ✅
default: ❌
protected: ❌
private: ❌
Персонал этого же ресторана (тот же пакет):
public: ✅
default: ✅
protected: ✅
private: ❌
Персонал филиала (другой пакет, но наследник):
public: ✅
default: ❌
protected: ✅
private: ❌
Управляющий (дочерний класс):
public: ✅
default: ✅
protected: ✅
private: ❌
Сам класс YakinikuShop:
public: ✅
default: ✅
protected: ✅
private: ✅
👉 Java PortalВ Spring Boot можно задать таймаут для graceful shutdown через настройку spring.lifecycle.timeout-per-shutdown-phase.
Graceful shutdown помогает избежать резких обрывов HTTP-запросов и преждевременных остановок потоков.
server:
shutdown: graceful
spring:
lifecycle:
timeout-per-shutdown-phase: 20s
# Сервер будет завершаться корректно (graceful).
# Даёт до 20 секунд на завершение запросов и работы бинов.
👉 Java PortalЗалетел полезняк для тех, кто готовится к собесам по Java или просто хочет быстро освежить базу.
На InterviewPrep выложили Java Notes (по сути мини-гайд/конспект) и там закрывают самые частые темы:
история Java JDK / JRE / JVM (как это вообще устроено) Collections управление памятью многопоточность обработка исключений типы классов типы данных и ключевые словаМожно прям как чеклист прогнать перед интервью. 👉 Java Portal
Spring Boot: если в приложении для REST-вызовов используется RestTemplate, таймауты можно централизованно настроить через RestTemplateBuilder.
@Configuration
public class RestTemplateConfig {
@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder) {
return builder
.setConnectTimeout(Duration.ofSeconds(3))
.setReadTimeout(Duration.ofSeconds(5))
.build();
}
}
Также можно завести больше одной конфигурации таймаутов через аннотацию @Qualifier:
@Bean
@Qualifier("slowServiceRestTemplate")
public RestTemplate slowServiceRestTemplate(RestTemplateBuilder builder) {
return builder
.setConnectTimeout(Duration.ofSeconds(5))
.setReadTimeout(Duration.ofSeconds(30))
.build();
}
@Autowired
@Qualifier("slowServiceRestTemplate")
private RestTemplate restTemplate;
👉 Java PortalОбъясни, какие паттерны проектирования Spring Boot использует внутри.
На собеседовании обычно проверяют не то, знаешь ли ты названия паттернов.
Скорее хотят понять, понимаешь ли ты, как Spring Boot архитектурно на них построен.
1. Singleton
Spring Boot бины по умолчанию singleton.
Когда ты помечаешь класс
@Component, @Service или @Repository, Spring по дефолту создаёт один инстанс.
Что можно сказать:
"Все Spring-бины по умолчанию singleton, если явно не указать другой scope, например @RequestScope. Это экономит память и держит объектный граф консистентным и разделяемым."
2. Proxy
Spring AOP (аспектно-ориентированное программирование) работает через прокси.
3. Observer
Система событий Spring это Observer в чистом виде.
4. Factory
Spring везде использует фабрики.
BeanFactory, ApplicationContext, FactoryBean.
Ты объявляешь бин, а Spring решает, когда и как его создать.
5. Builder
Используется в клиентах вроде RestTemplateBuilder, WebClient.Builder.
6. Template Method
Очень активно используется в JdbcTemplate, RestTemplate и т.д.
Что можно сказать:
"Мне не нужно париться про управление соединением и обработку исключений. Это делает шаблон, а я просто подставляю свою конкретную логику."
👉 Java PortalJava: исключения в Java делятся на две основные категории: checked и unchecked.
Checked-исключения нужно либо перехватывать, либо объявлять.
Unchecked-исключения не нужно объявлять в throws у метода, и компилятор не требует их перехватывать, хотя при необходимости их тоже можно ловить.
// Проверяемые (checked)
try {
FileReader reader = new FileReader("file.txt"); //FileNotFoundException (проверяемое)
} catch (FileNotFoundException e) {
e.printStackTrace();
}
// Непроверяемые (unchecked)
String nullText = null;
System.out.println(nullText.length()); //NullPointerException (непроверяемое)
👉 Java PortalРеализация гексагональной архитектуры на Java
В данной статье рассматривается архитектура проекта, позволяющая модульным образом интегрировать инфраструктурные фреймворки, такие как Spring, Quarkus и Micronaut, без необходимости модификации ядра предметной области (domain) или внешних API.
👉 Java Portal
Java-совет : выносите повторяющуюся логику в небольшие вспомогательные классы, но не скатывайтесь в всезнающие God-классы.
Пример helper-класса:
public class TextUtils {
public static String capitalize(String str) {
...
}
...
}
А вот это уже God-класс:
public class DoThings {
public void addTask(String task) { ... }
public void saveToFile(String filename) { ... }
public void logError(String error) { ... }
...
}
Он делает слишком много несвязанных вещей.
👉 Java PortalВ старые времена на Java самое дорогое выражение, которое я видел в проде, выглядело невинно:
→ repository.findAll()
Компилируется, тесты проходит, на QA тоже всё ок потому что данных мало.
А потом в проде прилетает реальный трафик, JVM начинает пухнуть от хипа и p99 улетает в космос. Причина простая — вызов неограниченный по объёму. Без лимитов, без пагинации, без стриминга.
показательный случай про цену подобных ошибок:
• ракета Ariane 5
• стоимость проекта — 370 млн
• в коде было преобразование 64-битного значения к 16-битному
• при ускорении значение вышло за пределы
• произошёл overflow, навигация отказала
• запуск провалился, 370 млн просто улетели
Вывод: неограниченные операции в коде — всегда риск.
Из той же категории:
• collect(toList()) на огромных стримах
•
@Transactional прямо на контроллерах
• synchronized на нагруженном месте
👉 Java PortalНовый способ регистрировать бины программно начиная со Spring Framework 7 👇👇👇
@Configuration
@Import(ExampleRegistrar.class)
class ExampleConfiguration {
}
class ExampleRegistrar implements BeanRegistrar {
@Override
public void register(BeanRegistry registry, Environment env) {
if (env.matchesProfiles("dev")) {
registry.registerBean(ExampleInMemoryRepository.class);
} else {
registry.registerBean(ExampleRepository.class);
}
}
}
👉 Java PortalJetBrains вбросили загадку про IntelliJ IDEA. Судя по всему, кто-то пытается незаметно попасть на их день рождения. Команда решила устроить мини-квест: каждый день будет новая задачка, новые подсказки и в итоге надо вычислить тайного гостя вечеринки. 😂
В первом задании предлагают сопоставить сниппеты кода с версиями Java. Там набор вполне узнаваемых фич: var, streams, diamond-оператор, enum и records. Ниже варианты: Java 5, 7, 8, 11, 17 и 21.
Выглядит легко, но подана история забавно, а оформление в стиле карты-загадки.
👉 Java Portal
Spring Boot: можно переопределять конфиги на рантайме без перепаковки приложения.
Spring Boot по умолчанию использует лаунчер JarLauncher, который позволяет переопределить дефолтную конфигурацию через параметр loader.path при запуске приложения.
Предположим, у вас есть Spring Boot приложение со следующими зависимостями:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
С application.properties такого вида:
demo.message=Hello from inside the JARИ простой контроллер:
@RestController
public class HelloController {
@Value("${demo.message}")
private String message;
@GetMapping("/")
public String hello() {
return message;
}
}
Если собрать jar и запустить:
java -jar springboot-propertieslauncher-demo-0.0.1-SNAPSHOT.jar
Открыв [http://localhost:8080](http://localhost:8080) вы получите:
Hello from inside the JARЕсли теперь создать внешний файл application.properties в той же директории, где лежит jar:
demo.message=Hello from outside the JARИ запустить приложение с параметром loader.path, указывающим на текущую директорию:
java -jar springboot-propertieslauncher-demo-0.0.1-SNAPSHOT.jar --loader.path=.
Перейдя в [http://localhost:8080](http://localhost:8080) будет:
Hello from outside the JAR👉 Java Portal
Что такое Throwable
Throwable в Java — это базовый класс для всех «бросаемых» аномалий. Он даёт общий функционал для работы с исключениями: стек, причину, вложенные ошибки и т. д.
С точки зрения модели: невосстанавливаемые критические состояния представлены через Error, а ошибки уровня приложения — через Exception.
То есть всё, что можно бросать (throw), наследуется от Throwable.
Коротко:
Error: обычно невосстанавливаемая и не предполагается обработка на уровне приложения
Exception: приложение может предусматривать и обрабатывать
checked: обработка контролируется компилятором
unchecked: обработка не принудительная
Иерархия выглядит примерно так:
java.lang.Object
└─ java.lang.Throwable // всё, что можно throw-нуть
├─ java.lang.Error // системные критические сбои
│ ├─ OutOfMemoryError
│ ├─ StackOverflowError
│ ├─ VirtualMachineError
│ └─ ...
└─ java.lang.Exception // исключения уровня приложения
├─ RuntimeException // unchecked
│ ├─ NullPointerException
│ ├─ IllegalArgumentException
│ ├─ IndexOutOfBoundsException
│ └─ ...
└─ IOException, SQLException (checked)
Разница между Error и Exception
Error — «фатальный и невосстанавливаемый сбой»
Exception — «аномалия, которую приложение может ожидать и обрабатывать»
Мини сравнение:
источник: Error приходит от JVM и рантайма, Exception рождается на уровне приложения
восстановление: у Error почти нулевые шансы, у Exception всё зависит от ситуации
catch: Error обычно не ловят, Exception ловят и обрабатывают
примеры: для Error — OOM, StackOverflow; для Exception — неверный ввод или I/O ошибки
Что такое Error
Это фатальные сбои JVM.
Не то, что будут фиксить в бизнес-логике.
Примеры: OutOfMemoryError, StackOverflowError, VirtualMachineError
Почему их не ловят?
предпосылки работы программы уже нарушены
даже если поймать — непонятно, что делать дальше
нормальная стратегия — дать процессу упасть
Что такое Exception
Это исключения, которые приложение может предусматривать и включать в контрольный поток.
checked: IOException, SQLException
unchecked: NullPointerException, IllegalArgumentException
Почему их обрабатывают?
Потому что они «возможны по контракту» — неверный ввод, I/O, бизнес-валидация и т. д.
Почему в GlobalExceptionHandler не ловят Throwable
Потому что обработка Throwable приводила бы к поглощению Error (фатальных ошибок), и приложение продолжило бы работать в «сломанных» условиях.
Подробности:
➡️Поглощение Error
Если OutOfMemoryError превратить в обычный 500, то это попытка «делать вид, что всё ок», в то время как приложение фактически в предсмертном состоянии.
➡️Ломается контрольный поток фреймворка
Например, в Spring разное поведение завязано на тип исключения. Throwable ломает эти правила.
➡️Падает наблюдаемость
«Ловить всё» засоряет логи шумом и усложняет поиск корня проблемы.
Отсюда правило: в GlobalExceptionHandler ловят не Throwable, а Exception (или RuntimeException) как конечный уровень обработки в приложении.
👉 Java Portal
现已上线!2025 年 Telegram 研究 — 年度关键洞察 
