Java进程在重负载下不会在SIGTERM上退出

Question

在正常操作中，当我的应用程序被发送一个“kill -s SIGTERM”时，它可以正常退出。

然而，在负载下，有时进程不退出。

我只是想知道有没有可能http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6392332原因是什么，或者可能是其他原因？

以下是有问题的过程的堆栈跟踪的某些部分，显示了关闭方法，任何帮助都非常感谢。

请注意，这是一个在 64 位 RHEL 6.3 上运行的 Java 进程。

2013-05-22 08:01:33 
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode): 

...

"Thread-15" prio=10 tid=0x000000001994d000 nid=0x4d5a waiting on condition [0x00007f4da08a3000] 
   java.lang.Thread.State: TIMED_WAITING (parking) 
at sun.misc.Unsafe.park(Native Method) 
- parking to wait for <0x000000079fd9fce8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082) 
at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1468) 
at org.jboss.netty.util.internal.ExecutorUtil.terminate(ExecutorUtil.java:109) 
at org.jboss.netty.util.internal.ExecutorUtil.terminate(ExecutorUtil.java:49) 
at org.jboss.netty.channel.socket.nio.AbstractNioWorkerPool.releaseExternalResources(AbstractNioWorkerPool.java:77) 
at org.jboss.netty.channel.socket.nio.NioServerSocketChannelFactory.releaseExternalResources(NioServerSocketChannelFactory.java:164) 
at com.test.services.radius.server.RadiusServerImpl.stop(RadiusServerImpl.java:87) 
at com.test.services.radius.ServiceProvider.unload(ServiceProvider.java:61) 
at com.test.spf.ServiceProviderCacheImpl.clearCurrentCache(ServiceProviderCacheImpl.java:150) 
- locked <0x00000006b8968038> (a com.test.spf.ServiceProviderCacheImpl) 
at com.test.spf.ServiceProviderCacheImpl.unload(ServiceProviderCacheImpl.java:170) 
at com.test.spf.SPAImpl.stop(SPAImpl.java:178) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:601) 
at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:273) 
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:199) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:487) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:463) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:480) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:463) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:480) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:463) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:480) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:463) 
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:431) 
- locked <0x00000006da966290> (a java.util.LinkedHashMap) 
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1048) 
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1022) 
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:970) 
- locked <0x000000073ad1a920> (a java.lang.Object) 
at org.springframework.web.context.ContextLoader.closeWebApplicationContext(ContextLoader.java:384) 
at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:78) 
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4245) 
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4886) 
- locked <0x00000006b8968118> (a org.apache.catalina.core.StandardContext) 
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:936) 
at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1359) 
at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1330) 
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:326) 
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) 
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1098) 
- locked <0x00000006b89682f8> (a org.apache.catalina.core.StandardHost) 
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1110) 
- locked <0x000000068e63ff10> (a org.apache.catalina.core.StandardEngine) 
at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:468) 
at org.apache.catalina.core.StandardService.stop(StandardService.java:604) 
- locked <0x000000068e63ff10> (a org.apache.catalina.core.StandardEngine) 
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:788) 
at org.apache.catalina.startup.Catalina.stop(Catalina.java:662) 
at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:706) 

"SIGTERM handler" daemon prio=10 tid=0x0000000025453000 nid=0x4d58 in Object.wait() [0x00007f4da0b2f000] 
   java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
- waiting on <0x000000072c10db20> (a org.apache.catalina.startup.Catalina$CatalinaShutdownHook) 
at java.lang.Thread.join(Thread.java:1258) 
- locked <0x000000072c10db20> (a org.apache.catalina.startup.Catalina$CatalinaShutdownHook) 
at java.lang.Thread.join(Thread.java:1332) 
at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106) 
at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46) 
at java.lang.Shutdown.runHooks(Shutdown.java:123) 
at java.lang.Shutdown.sequence(Shutdown.java:167) 
at java.lang.Shutdown.exit(Shutdown.java:212) 
- locked <0x0000000707855738> (a java.lang.Class for java.lang.Shutdown) 
at java.lang.Terminator$1.handle(Terminator.java:52) 
at sun.misc.Signal$1.run(Signal.java:212) 
at java.lang.Thread.run(Thread.java:722) 

Answer 1

在所有线程都正确完成之前，任何Unix进程都不会在SIGTERM上完成，从而从run方法返回。高负载可能源于死锁-死锁的线程通常永远不会结束。或者某些线程中的无休止循环。

顺便说一下，关闭Tomcat的正确方法是使用捆绑的关闭脚本。在一些特殊的情况下，它可能会失败，但是你可以用信号杀死它。

SIGTERM或SIGKILL，这通常是商业问题。当复杂的应用程序被交换时，正常关机很容易需要15分钟以上...所以你能忍受15分钟的停机时间吗？或者你会在接下来的2分钟内停下来重新开始？