Java Portal | Программирование
Присоединяйтесь к нашему каналу и погрузитесь в мир для 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), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
application.properties поставь:
spring.main.lazy-initialization=true
Но в проде важно оставить дефолтное поведение, потому что:
1. Ошибки старта ловятся раньше
2. Все компоненты сразу готовы принимать запросы
👉 Java Portal@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@Component
public class StartupRunner implements CommandLineRunner {
@Override
public void run(String... args) {
System.out.println("Приложение запущено! Дальнейшая настройка");
}
}
👉 Java Portalpackage 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 Portalserver:
shutdown: graceful
spring:
lifecycle:
timeout-per-shutdown-phase: 20s
# Сервер будет завершаться корректно (graceful).
# Даёт до 20 секунд на завершение запросов и работы бинов.
👉 Java Portalистория Java JDK / JRE / JVM (как это вообще устроено) Collections управление памятью многопоточность обработка исключений типы классов типы данных и ключевые словаМожно прям как чеклист прогнать перед интервью. 👉 Java Portal
@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@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 Portal// Проверяемые (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 Portalpublic 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@Transactional прямо на контроллерах
• synchronized на нагруженном месте
👉 Java Portal@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 Portal<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
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
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
