Java Portal | Программирование
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
Показати більше📈 Аналітичний огляд Telegram-каналу Java Portal | Программирование
Канал Java Portal | Программирование (@java_iibrary) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 11 922 підписників, посідаючи 10 472 місце в категорії Технології та додатки та 53 940 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 11 922 підписників.
За останніми даними від 26 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 288, а за останні 24 години на 14, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 10.39%. Протягом перших 24 годин після публікації контент зазвичай збирає 6.42% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 1 239 переглядів. Протягом першої доби публікація в середньому набирає 766 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 3.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як boot, string, void, архитектура, resttemplate.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
Завдяки високій частоті оновлень (останні дані отримано 27 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
logging.console.enabled=false
Полезно в контейнерах, где логи собираются только из файлов или через OTLP
При необходимости можно оставить file appenders или remote appenders
👉 Java PortalThread.sleep() для ожидания выполнения работы — используйте синхронизацию или scheduler.
Это всего лишь предположение о времени: выполнение может возобновиться слишком рано или слишком поздно.
Для координации используйте wait() / notify() или CountDownLatch.
Для повторяющихся задач используйте ScheduledExecutorService.
👉 Java Portalnow() — это не «сейчас», а скорее «когда-то было сейчас».
На самом деле now() возвращает время начала текущей транзакции. Реальные часы продолжают идти, но каждый последующий вызов now(), CURRENT_TIMESTAMP, CURRENT_TIME и CURRENT_DATE внутри этой же транзакции всё равно возвращает одно и то же время.
В Postgres это называется transaction-frozen timestamp.
То есть INSERT на 10 000 строк с created_at DEFAULT now() получит один и тот же timestamp для всех строк, а не 10 000 слегка отличающихся значений.
Три варианта времени:
• now() — традиционный для Postgres вариант, хотя он есть и в других СУБД, но это не стандарт SQL. В стандарте SQL используется CURRENT_TIMESTAMP. В Postgres также есть transaction_timestamp(), который работает так же, как now(), но хотя бы честно говорит об этом своим названием.
• statement_timestamp() обновляется один раз на каждый SQL-запрос. Это полезно внутри длинной транзакции, когда вам нужно фиксировать время выполнения отдельных команд, но не переходить к реальному системному времени.
• clock_timestamp() — единственный timestamptz, который меняется даже во время выполнения одного SQL-запроса.
👉 Java Portalnow() — это не «сейчас», а скорее «когда-то было сейчас».
На самом деле now() возвращает время начала текущей транзакции. Реальные часы продолжают идти, но каждый последующий вызов now(), CURRENT_TIMESTAMP, CURRENT_TIME и CURRENT_DATE внутри этой же транзакции всё равно возвращает одно и то же время.
В Postgres это называется transaction-frozen timestamp.
То есть INSERT на 10 000 строк с created_at DEFAULT now() получит один и тот же timestamp для всех строк, а не 10 000 слегка отличающихся значений.
Три варианта времени:
• now() — традиционный для Postgres вариант, хотя он есть и в других СУБД, но это не стандарт SQL. В стандарте SQL используется CURRENT_TIMESTAMP. В Postgres также есть transaction_timestamp(), который работает так же, как now(), но хотя бы честно говорит об этом своим названием.
• statement_timestamp() обновляется один раз на каждый SQL-запрос. Это полезно внутри длинной транзакции, когда вам нужно фиксировать время выполнения отдельных команд, но не переходить к реальному системному времени.
• clock_timestamp() — единственный timestamptz, который меняется даже во время выполнения одного SQL-запроса.
👉 Java Portallogging.console.enabled=false
✅ Полезно в контейнерах, где логи собираются только из файлов или через OTLP
✅ При необходимости можно оставить файловые или удалённые appenders
#SpringBoot4 #Logging
👉 Java PortalWHERE, независимыми друг от друга.
Например, для такого SQL-запроса:
SELECT *
FROM world
WHERE country = 'Japan'
AND continent = 'Asia';
планировщик оценивает количество подходящих строк, перемножая селективность каждого условия.
Допустим, селективность условия country = 'Japan' равна 0,02, а continent = 'Asia' — 0,4. Тогда общую селективность планировщик оценит как 0,008.
В действительности эти столбцы связаны, поэтому итоговая селективность равна селективности условия country = 'Japan'.
Чтобы исправить оценку, нужно явно указать корреляцию между столбцами: выполнить CREATE STATISTICS для них вместе, а затем запустить ANALYZE.
Я проверил это на тестовом датасете, результаты видны на изображении. Изначально планировщик ожидал, что запрос вернёт 784 строки, хотя фактический результат составлял 2000 строк.
После выполнения CREATE STATISTICS планировщик спрогнозировал 1983 строки — гораздо ближе к реальному результату.
👉 Java Portalspring.data.redis.masterreplica.nodes
✅ Запросы на чтение можно отправлять на реплики
✅ Работает только с Lettuce, без поддержки Jedis
👉 Java Portal