Java Portal | Программирование
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
Ko'proq ko'rsatish📈 Telegram kanali Java Portal | Программирование analitikasi
Java Portal | Программирование (@java_iibrary) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 12 130 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 10 402-o'rinni va Rossiya mintaqasida 54 525-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 12 130 obunachiga ega bo‘ldi.
07 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -138 ga, so‘nggi 24 soatda esa 2 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 11.37% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 6.26% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 1 379 marta ko‘riladi; birinchi sutkada odatda 760 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 4 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent boot, string, void, архитектура, resttemplate kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 08 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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
Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
