Все с пелёнок знают о существовании 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