Утечка памяти ExecutorService при исключении

Question

Мне трудно отследить это, поскольку профилировщик продолжает падать (ошибка горячей точки). Прежде чем я углублюсь в выяснение этого, я хотел бы знать, действительно ли у меня есть проблема или нет: -)

У меня есть несколько пулов потоков, созданных с помощью: Executors.newFixedThreadPool (10); Потоки подключаются к разным веб-сайтам, и иногда я получаю отказ в соединении и в результате получаю исключение.

Когда я позже вызову Future.get () для получения результата, он будет перехватывать исключение ExecutionException, которое оборачивает исключение, которое было выброшено при невозможности установить соединение.

Программа использует довольно постоянный объем памяти вплоть до момента времени, когда создаются исключения (они, как правило, происходят в пакетном режиме, когда конкретный сайт перегружен). После этой точки память снова остается постоянной, но на более высоком уровне.

Так что мой вопрос в том, является ли поведение памяти (сообщаемое "top" в Unix) ожидаемым, потому что исключения только что-то сработали, или у меня, возможно, есть фактическая утечка, которую мне нужно отследить? Кроме того, когда Future.get () генерирует исключение, есть ли что-то еще, что мне нужно сделать, кроме перехвата исключения (например, вызова Future.cancel () для него)?

РЕДАКТИРОВАТЬ: поэтому я рассказал о нескольких инструментах, и с точки зрения Java, нет ничего, что могло бы привести к утечке памяти. Я поиграюсь с другим кодом, который живет долго и через некоторое время выдает исключение, и посмотрю, увеличивается ли память, сообщаемая "top". Похоже, это может быть какая-то странность.

Answer 1

Ваш Java-процесс вообще завершается с исключением java.lang.OutOfMemoryError? Если нет, маловероятно, что у вас есть утечка. Конечно, вы всегда можете подключиться к процессу Java с помощью JConsole, захватить дамп кучи и открыть его в бесплатном инструменте, таком как HPjmeter , чтобы действительно быстро это выяснить.

Answer 2

JVM начнется с Xms amout кучи, а затем перехватит больше из системы до Xmx. Даже если GC освобождает кучу в JVM, процесс java продолжает удерживать кучу, которую он извлек из ОС (поэтому в top он никогда не уменьшается) (Опыт работы с Sun JVM (Java1.5 / 6) в Redhat Linux).

Вполне возможно, что куча освобождается и доступна, но она не передается в ОС, а в top Java, похоже, использует много кучи.

Вы можете использовать visualvm , инструмент, который поставляется с JDK. Просто запустите ваше приложение. в течение длительного времени подключите инструмент и посмотрите на кучную телеметрию. Если он продолжает постепенно расти, это может быть утечка памяти. Вы также можете получить дамп кучи с помощью этого инструмента и посмотреть, какие объекты накапливаются.