Имеется приложение (обработка документов, приходящих почтой), где основной поток обработки разделен на несколько Threads.
Естественно, имеется необходимость при завершении сервиса корректно их останавливать (фактически, делать в "безопасном" месте break внутри цикла Run).

Что пробовалось:
- отработка InterruptedException (который вокруг sleep)
- вызов Thread.interrupt() из finalize() центрального класса
- отработка this.interrupt() в finalize() каждого треда - аналогично

И вот глядение в логи убедило, что даже все три метода вместе не дают возможности корректно отловить момент остановки сервиса и быстро завершить текущие операции (хотя finalize вроде железно должно это делать). Вопрос: что я делаю не так, и есть ли стандартный способ корректно останавливать треды? Реально надо "продержать" их максимум секунду, чтобы успеть, скажем, принять письмо и закрыть рор3-сессию, или завершить начатую обработку документа.

Все, сам разобрался... Runtime.addShutdownHook() рулит:)
Честно говоря, до сего момента был уверен, что перед шатдауном ВСЕ живые объекты корректно финализируются JVM, ан нет.

котыможет, тупой вопрос, но при чем тут томкет?

Да это я ступил. Просто было святое убеждение, что сервера должны финализировать при шатдауне важные объекты (скажем, bean в скоупе Application) сами, или уж по крайней мере интерраптить все не-даймон треды.
Собственно, убеждение было основано на том, что при работе с каким-то стареньким Джейраном таких проблем не возникало - обработчики не сыпались "на самом интересном месте".

А вот это мысль... потому что с addShutdownHook тоже как-то кисленько, а сервлет Startup с методом init() у меня уже есть - как раз те самые сервисы и инициализируются, которые в конце надо прибивать.
Спасибо, завтра с утречка опробую:)

Но вот что меня интересует: почему же в старом джейране таких фишек не было? Действительно разница в поведении двух вебсерверов, или что-то менее очевидное?

peter6636 Не совсем.
При уборке мусора в Java для идентификации используемых объектов применяется механизм, кот. наз. проверкой достижимости объектов.Изменение состояния объекта от момента создания до момента уничтожения называется жизненным цмклом.Утечка памяти в Java возникает обычно тогда,когда доступный объект с длинным жизненным циклом содержит ссылку на объект с коротким жизненным циклом.Короче говоря блин, к утечкам памяти относятся доступные, но не используемые объекты,ищи их.

Нет, тут дело немного не в том. У меня есть треды, которые "вечно живые", т.е. крутятся все время работы приложения. Они, естественно, никакому gc не подлежат. Весь смысл был сделать им interrupt в момент шатдауна и дождаться (буквально секунду) пока каждый из них доделает некий критичный участок кода и выскочит из run().
Дык вот, я был свято уверен, что перед выходом JVM финализирует вообще ВСЕ объекты (т.е. все, что есть, считает мусором и прибивает). Оказалось - фигушки. Есть некий метод в System.runFinalizersOnExit(boolean), который задает это явно, но вызывать его категорически не рекомендуют, вместо него советуя Runtime.addShutdownHook(); как оказалось, в Томкате и эта байда нагло игнорируется (видимо, прибивается через security manager, я не разбирался). Во всяком случае, хук нифига не отрабатывал.
А вот добавил в уже имевшийся класс Startup кроме метода init() еще и destroy() - все прекрасно начало корректно останавливать обработку, я сегодня целый день с этого счастливый, спасибо usa:-)