Все с пелёнок знают о существовании String Pool 🏊♀️
Полезная вещь для экономии памяти. Но единственный ли это пул в java?
В Integer, том самом классе-обертке для самого используемого примитива, есть внутренний класс IntegerCache - пул целых чисел в промежутке [-128; 127], так как в большинстве случаев используются числа как раз в этих пределах. Он объявлен как private static. В этом внутреннем классе кэшированные объекты находятся в массиве cache[].
Кэширование выполняется при первом использовании класса-обертки. После этого вместо создания нового экземпляра (кроме явного использования конструктора, конечно), используются кэшированные объекты, JVM берет их из пула✍🏻
⬇️⬇️⬇️
И каверзный вопрос
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤4🤔2
💡 Почему приложение теряет соединение с базой данных? Разбираем на примере реальной ошибки
🔍 Ситуация:
Приложение работает, но через какое-то время начинаются странности: база данных внезапно "отказывает", в логах ошибки
JDBCConnectionException - Unable to acquire JDBC Connection
и если присмотреться - рядом еще
SocketException - Too many open files .
О каких files речь и почему это мешает подключению к БД?
Вы проверяете PostgreSQL — соединений немного (ну вдруг "too many" как-то относится к соединениям), всё в порядке. В чём же проблема?
🕵️ Ответ скрыт на уровне операционной системы:
Ошибка Too many open files говорит о том, что приложение исчерпало лимит файловых дескрипторов. Linux (на сервере с вашим приложением) выделяет каждому процессу ограниченное количество дескрипторов, которые используются не только для работы с файлами, но и для сетевых соединений (сокетов)!
Если в приложении какие-то ресурсы (например, сокеты или файлы) открываются, но не закрываются, дескрипторы "утекают". В итоге, когда приложение пытается установить новое соединение с базой данных, система просто не может выделить дескриптор для нового сокета.
⚙️ Причина оказывается не в базе, а в куче "забытых" файлов или других ресурсов.
🔧 Как избежать?
Проблема решается дисциплиной работы с ресурсами. Можно использовать автоматические механизмы языка, такие как try-with-resources, или следить за ручным закрытием.
🛠 Вывод:
Ошибка соединения с базой данных и лимит открытых файлов на первый взгляд не связаны, но на практике это замкнутая цепь. Утечки файлов → превышение лимита дескрипторов → невозможность создать сокет → сбой подключения к БД.
В следующих постах расскажем как ручками проверить количество активных, ожидающих и зависших подключений к БД.
🔍 Ситуация:
Приложение работает, но через какое-то время начинаются странности: база данных внезапно "отказывает", в логах ошибки
JDBCConnectionException - Unable to acquire JDBC Connection
SocketException - Too many open files
О каких files речь и почему это мешает подключению к БД?
Вы проверяете PostgreSQL — соединений немного (ну вдруг "too many" как-то относится к соединениям), всё в порядке. В чём же проблема?
🕵️ Ответ скрыт на уровне операционной системы:
Ошибка Too many open files говорит о том, что приложение исчерпало лимит файловых дескрипторов. Linux (на сервере с вашим приложением) выделяет каждому процессу ограниченное количество дескрипторов, которые используются не только для работы с файлами, но и для сетевых соединений (сокетов)!
Если в приложении какие-то ресурсы (например, сокеты или файлы) открываются, но не закрываются, дескрипторы "утекают". В итоге, когда приложение пытается установить новое соединение с базой данных, система просто не может выделить дескриптор для нового сокета.
⚙️ Причина оказывается не в базе, а в куче "забытых" файлов или других ресурсов.
🔧 Как избежать?
Проблема решается дисциплиной работы с ресурсами. Можно использовать автоматические механизмы языка, такие как try-with-resources, или следить за ручным закрытием.
🛠 Вывод:
Ошибка соединения с базой данных и лимит открытых файлов на первый взгляд не связаны, но на практике это замкнутая цепь. Утечки файлов → превышение лимита дескрипторов → невозможность создать сокет → сбой подключения к БД.
В следующих постах расскажем как ручками проверить количество активных, ожидающих и зависших подключений к БД.
❤6🆒3✍2
💡 Совет: как ускорить отладку
В процессе дебага нужно проверить небольшое изменение в методе, но перезапускать всё приложение ради одной строки кода — слишком долго? Используйте механизм HotSwap для быстрого внесения изменений:
1️⃣ Запускаете Debug Mode.
2️⃣ Делаете изменения в коде.
3️⃣ Заходите в меню Build - пункт Recompile 'ChangedClass.java' (или просто Ctrl+Shift+F9), в окошке жмёте Reload -> видите сообщение о том, что один класс reloaded.
4️⃣ Как ни в чем не бывало продолжаете дебажить код, но уже с изменениями.
⚠️ Ограничения:
Работает только для изменений в методах (без добавления новых полей/методов/классов).
Более сложные изменения могут потребовать использования инструментов, таких как JRebel.
🚀 Итог: вместо долгого перезапуска вы сразу видите результат изменений в работе приложения. Попробуйте — это действительно экономит время!
P.S. Речь про Idea, конечно же
В процессе дебага нужно проверить небольшое изменение в методе, но перезапускать всё приложение ради одной строки кода — слишком долго? Используйте механизм HotSwap для быстрого внесения изменений:
1️⃣ Запускаете Debug Mode.
2️⃣ Делаете изменения в коде.
3️⃣ Заходите в меню Build - пункт Recompile 'ChangedClass.java' (или просто Ctrl+Shift+F9), в окошке жмёте Reload -> видите сообщение о том, что один класс reloaded.
4️⃣ Как ни в чем не бывало продолжаете дебажить код, но уже с изменениями.
⚠️ Ограничения:
Работает только для изменений в методах (без добавления новых полей/методов/классов).
Более сложные изменения могут потребовать использования инструментов, таких как JRebel.
🚀 Итог: вместо долгого перезапуска вы сразу видите результат изменений в работе приложения. Попробуйте — это действительно экономит время!
P.S. Речь про Idea, конечно же
1🔥6❤5👍4✍2
✨Иногда в пылу разработки мы забиваем забываем об одной важной детали при работе с реляционными БД — индексах на внешних ключах
🔍Казалось бы, мелочь: зачем заморачиваться с ещё одним индексом, если сам внешний ключ уже прописан? Но именно индекс по FK способен ускорить join-запросы (а также каскадное удаление), особенно при работе с большими объёмами данных. Еще и общая нагрузка на систему снижается. В результате вы получаете более отзывчивое приложение и довольных пользователей
✅Если у вас в базе есть внешние ключи (а они есть), убедитесь, что к ним привязаны соответствующие индексы — и ваша СУБД скажет вам спасибо
upd
в комментах вскрылось, что по этому поводу говорит оф.документация по постгресу ⬇️
🔍Казалось бы, мелочь: зачем заморачиваться с ещё одним индексом, если сам внешний ключ уже прописан? Но именно индекс по FK способен ускорить join-запросы (а также каскадное удаление), особенно при работе с большими объёмами данных. Еще и общая нагрузка на систему снижается. В результате вы получаете более отзывчивое приложение и довольных пользователей
✅Если у вас в базе есть внешние ключи (а они есть), убедитесь, что к ним привязаны соответствующие индексы — и ваша СУБД скажет вам спасибо
upd
в комментах вскрылось, что по этому поводу говорит оф.документация по постгресу ⬇️
1👍6🔥6💯3