Java Portal | Программирование
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
نمایش بیشتر📈 تحلیل کانال تلگرام Java Portal | Программирование
کانال Java Portal | Программирование (@java_iibrary) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 12 121 مشترک است و جایگاه 10 397 را در دسته فناوری و برنامهها و رتبه 54 492 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 12 121 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 08 ژوئن, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -138 و در ۲۴ ساعت گذشته برابر -5 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 11.21% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 6.34% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 1 360 بازدید دریافت میکند. در اولین روز معمولاً 769 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 4 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند boot, string, void, архитектура, resttemplate تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 09 ژوئن, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
@Transactional не работает, когда ты вызываешь метод из другого метода в том же классе?
Это не баг, а классическая особенность Spring AOP по дизайну.
Знаешь, почему транзакция вообще не стартует?
Проблема в том, как Spring AOP создаёт прокси. Когда ты ставишь @Transactional на метод, Spring не правит байткод класса. Вместо этого он создаёт прокси-объект, который оборачивает твой бин.
Этот прокси перехватывает внешние вызовы метода, запускает транзакцию и потом делегирует вызов реальному методу бина.
Это отлично работает, когда внешний бин вызывает твой публичный транзакционный метод, потому что вызов проходит через прокси.
Но при самовызове внутри класса (например, this.someTransactionalMethod()) ты вызываешь метод напрямую на целевом объекте (this), а не через прокси. Транзакционный advice прокси полностью обходится, поэтому транзакция не стартует. Это фундаментальное следствие прокси-based AOP.
Чтобы исправить, самое чистое и продакшен-готовое решение это вынести транзакционный метод в отдельный Spring-бин и инжектить его. Тогда вызов всегда будет внешним и пройдёт через прокси, корректно поднимая транзакцию каждый раз. 🙈
👉 Java PortalДо 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
اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
