Назад | Перейти на главную страницу

Утечка памяти в Tomcat

Я использую Tomcat 6.0, JDK 1.6 для веб-приложения.

Он часто умирает, требуя перезагрузки вручную, и файл журнала показывает это:

Примечание: максимальное количество потоков (200), созданных для соединителя с нулевым адресом и портом 80

Далее следует:

Примечание. Ожидается освобождение 200 экземпляров.

Далее следуют 200 строк этого:

Серьезная: веб-приложение [] все еще обрабатывает запрос, который еще не завершен. Это может привести к утечке памяти. Вы можете контролировать время, отведенное для завершения запросов, с помощью атрибута unloadDelay стандартной реализации Context.

Далее следуют 200 строк этого:

Серьезная: веб-приложение [] создало ThreadLocal с ключом типа [net.sourceforge.jtds.jdbc.DateTime $ 1] (значение [net.sourceforge.jtds.jdbc.DateTime$1@1d51620]) и значением типа [java .util.GregorianCalendar] (значение [java.util.GregorianCalendar [time = 1304607600000, areFieldsSet = true, areAllFieldsSet = false, lenient = true, zone = sun.util.calendar.ZoneInfo [id = "Asia / Seoul", offset = 32400000, dstSavings = 0, useDaylight = false, transitions = 14, lastRule = null], firstDayOfWeek = 1, minimalDaysInFirstWeek = 1, ERA = 1, YEAR = 2011, MONTH = 4, WEEK_OF_YEAR = 19, WEEK_OF_MONTH = 1_MONTH = 1_MONTH = 1_DAY_MONTH = 1_ , DAY_OF_YEAR = 126, DAY_OF_WEEK = 6, DAY_OF_WEEK_IN_MONTH = 1, AM_PM = 0, HOUR = 0, HOUR_OF_DAY = 0, MINUTE = 0, SECOND = 0, MILLISECOND = 0, ZONE_OFETST = 0_OFET = 0, ZONE_000], но DAY_OFETST = от 0_OFETST = от 0_OFETST = от 0_OFETST = 0_OFETST = 0_OFET = 0_000] удалите его, когда веб-приложение было остановлено. Это может привести к утечке памяти.

Я рассматриваю это как GregorianCalendar протекает и не загружается как обычно.

Сайт довольно часто создает экземпляры GregorianCalendar, добавляет несколько месяцев или лет, форматирует полученную дату и выводит значение для пользователя. Однако я ожидаю, что экземпляр GregorianCalendar будет помечен для сбора, как только сервлет завершит свой метод обработки запроса.

В чем дело?

Вероятно, это не утечка памяти ... Ваш пул потоков коннектора имеет размер 200 (по умолчанию), и все 200 соединений используются, это показывает, что у вас есть 200 запросов, которые не завершены ... Остальные журналы созданы из-за того, что вы остановить Tomcat с этими 200 ожидающими запросами ... Итак, вопрос в том, почему ваши запросы не отвечают? Вы можете сделать дамп потока, чтобы увидеть, где запросы заблокированы ...