参考网址：http://tuhaitao.iteye.com/blog/1122935
http://blog.csdn.net/czcty/article/details/7898345
http://blog.csdn.net/parcel8437/article/details/7573963
tomcat/bin 目录下的catalina.sh是比较常用的shell
Shell代码
1. #启动tomcat
2. ./catalina.sh start
3.
4. #关闭tomcat
5. ./catalina.sh stop
往往一个工程，开发一段时间后，会发现./catalina.sh stop关闭不了tomcat，而必须使用kill -9 这样的强制命令去
杀死tomcat，这么做当然可以，但是手法不是那么的优雅
在tomat未被./catalina stop关闭的情况下，导致误以为tomcat已经关闭成功的哥们 会在更新完代码后，./catalina start一下，于是在服务器中就产生了2个tomcat的实例，log混乱，不知所措，ps 一看，大吃一惊，而后每次都用kill -9 才放心。
其实不用那样，一般关闭不了的情况，是由于程序员自己在tomcat中开启了新的线程，而且未设置成daemon，造成的主线程不能退出.
Java有两种Thread：“守护线程Daemon”与“用户线程User”。
用户线程：Java虚拟机在它所有非守护线程已经离开后自动离开。
守护线程：守护线程则是用来服务用户线程的，如果没有其他用户线程在运行，那么就没有可服务对象，也就没有理由继续下去。
容器只按照Java EE规范来管理应用中标准组件的生命周期，但你自己创建出来的资源要自己负责处理，容器是不会替你管理的。当线程只剩下守护线程的时候，JVM就会退出.但是如果还有其他的任意一个用户线程还在，JVM就不会退出.
那么怎么发现工程里到底哪里开启的新的非守护线程呢，其实jdk提供了jstack工具，可以帮助我们分析
查看方法很简单
$JAVA_HOME/bin/jstack
pid是指进程ID， 用ps -ef|grep tomcat 就可以查看到：
Shell代码
1. [root@localhost bin]# ps -ef|grep tomcat
2. root 1513 1 2 23:41 pts/1 00:00:01 /usr/local/share/java/jdk1.6.0_25/bin/java -Djava.util.logging.config.file=/opt/apache-tomcat-6.0.32/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/apache-tomcat-6.0.32/endorsed -classpath /opt/apache-tomcat-6.0.32/bin/bootstrap.jar -Dcatalina.base=/opt/apache-tomcat-6.0.32 -Dcatalina.home=/opt/apache-tomcat-6.0.32 -Djava.io.tmpdir=/opt/apache-tomcat-6.0.32/temp org.apache.catalina.startup.Bootstrap start
3. root 1544 1462 0 23:42 pts/1 00:00:00 grep --color=auto tomcat
这里看到的进程ID是 1513
调用jstack查看:
Shell代码
1. [root@localhost bin]# jstack 1513
2. 2011-07-12 23:44:00
3. Full thread dump Java HotSpot(TM) Client VM (20.0-b11 mixed mode, sharing):
4.
5. "Attach Listener" daemon prio=10 tid=0xb41d7c00 nid=0x606 waiting on condition [0x00000000]
6. java.lang.Thread.State: RUNNABLE
7.
8. "TP-Monitor" daemon prio=10 tid=0xb41d6400 nid=0x5fa in Object.wait() [0xb3e0b000]
9. java.lang.Thread.State: TIMED_WAITING (on object monitor)
10. at java.lang.Object.wait(Native Method)
11. - waiting on <0x87143720> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
12. at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:565)
13. - locked <0x87143720> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
14. at java.lang.Thread.run(Thread.java:662)
15.
16. "TP-Processor4" daemon prio=10 tid=0xb41d4c00 nid=0x5f9 runnable [0xb3e5c000]
17. java.lang.Thread.State: RUNNABLE
18. at java.net.PlainSocketImpl.socketAccept(Native Method)
19. at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
20. - locked <0x87124770> (a java.net.SocksSocketImpl)
21. at java.net.ServerSocket.implAccept(ServerSocket.java:462)
22. at java.net.ServerSocket.accept(ServerSocket.java:430)
23. at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:311)
24. at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:668)
25. at org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:879)
26. at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
27. at java.lang.Thread.run(Thread.java:662)
其中看到"Attach Listener" daemon prio=10 tid=0xb41d7c00 nid=0x606 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
这行，最前变的"Attach Listener" 是线程名， 紧跟其后的 daemon是线程的守护状态，
其中主线程不是daemon的，
"main" prio=10 tid=0xb6d05000 nid=0x5ea runnable [0xb6ee9000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x871644a8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at org.apache.catalina.core.StandardServer.await(StandardServer.java:431)
at org.apache.catalina.startup.Catalina.await(Catalina.java:676)
at org.apache.catalina.startup.Catalina.start(Catalina.java:628)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
在"main" 后没有daemon，看到这样的线程状态，：）
找到问题的根源后，我们可以这样处理：
1.将应用自己创建的线程、timer、scheduler这类的资源设为守护线程（daemon）。setDaemon(boolean on)方法可以方便的设置线程的Daemon模式，true为Daemon模式，false为User模式。
2.自己管理非守护线程的生命周期，当容器停止时手工释放资源。比如你可以在 Servlet 或 ServletContextListener 的 init 方法中初始化资源，在 destroy 方法中释放资源。
http://blog.csdn.net/czcty/article/details/7898345
http://blog.csdn.net/parcel8437/article/details/7573963
tomcat/bin 目录下的catalina.sh是比较常用的shell
Shell代码
1. #启动tomcat
2. ./catalina.sh start
3.
4. #关闭tomcat
5. ./catalina.sh stop
往往一个工程，开发一段时间后，会发现./catalina.sh stop关闭不了tomcat，而必须使用kill -9 这样的强制命令去
杀死tomcat，这么做当然可以，但是手法不是那么的优雅
在tomat未被./catalina stop关闭的情况下，导致误以为tomcat已经关闭成功的哥们 会在更新完代码后，./catalina start一下，于是在服务器中就产生了2个tomcat的实例，log混乱，不知所措，ps 一看，大吃一惊，而后每次都用kill -9 才放心。
其实不用那样，一般关闭不了的情况，是由于程序员自己在tomcat中开启了新的线程，而且未设置成daemon，造成的主线程不能退出.
Java有两种Thread：“守护线程Daemon”与“用户线程User”。
用户线程：Java虚拟机在它所有非守护线程已经离开后自动离开。
守护线程：守护线程则是用来服务用户线程的，如果没有其他用户线程在运行，那么就没有可服务对象，也就没有理由继续下去。
容器只按照Java EE规范来管理应用中标准组件的生命周期，但你自己创建出来的资源要自己负责处理，容器是不会替你管理的。当线程只剩下守护线程的时候，JVM就会退出.但是如果还有其他的任意一个用户线程还在，JVM就不会退出.
那么怎么发现工程里到底哪里开启的新的非守护线程呢，其实jdk提供了jstack工具，可以帮助我们分析
查看方法很简单
$JAVA_HOME/bin/jstack
pid是指进程ID， 用ps -ef|grep tomcat 就可以查看到：
Shell代码
1. [root@localhost bin]# ps -ef|grep tomcat
2. root 1513 1 2 23:41 pts/1 00:00:01 /usr/local/share/java/jdk1.6.0_25/bin/java -Djava.util.logging.config.file=/opt/apache-tomcat-6.0.32/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/apache-tomcat-6.0.32/endorsed -classpath /opt/apache-tomcat-6.0.32/bin/bootstrap.jar -Dcatalina.base=/opt/apache-tomcat-6.0.32 -Dcatalina.home=/opt/apache-tomcat-6.0.32 -Djava.io.tmpdir=/opt/apache-tomcat-6.0.32/temp org.apache.catalina.startup.Bootstrap start
3. root 1544 1462 0 23:42 pts/1 00:00:00 grep --color=auto tomcat
这里看到的进程ID是 1513
调用jstack查看:
Shell代码
1. [root@localhost bin]# jstack 1513
2. 2011-07-12 23:44:00
3. Full thread dump Java HotSpot(TM) Client VM (20.0-b11 mixed mode, sharing):
4.
5. "Attach Listener" daemon prio=10 tid=0xb41d7c00 nid=0x606 waiting on condition [0x00000000]
6. java.lang.Thread.State: RUNNABLE
7.
8. "TP-Monitor" daemon prio=10 tid=0xb41d6400 nid=0x5fa in Object.wait() [0xb3e0b000]
9. java.lang.Thread.State: TIMED_WAITING (on object monitor)
10. at java.lang.Object.wait(Native Method)
11. - waiting on <0x87143720> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
12. at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:565)
13. - locked <0x87143720> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
14. at java.lang.Thread.run(Thread.java:662)
15.
16. "TP-Processor4" daemon prio=10 tid=0xb41d4c00 nid=0x5f9 runnable [0xb3e5c000]
17. java.lang.Thread.State: RUNNABLE
18. at java.net.PlainSocketImpl.socketAccept(Native Method)
19. at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
20. - locked <0x87124770> (a java.net.SocksSocketImpl)
21. at java.net.ServerSocket.implAccept(ServerSocket.java:462)
22. at java.net.ServerSocket.accept(ServerSocket.java:430)
23. at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:311)
24. at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:668)
25. at org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:879)
26. at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
27. at java.lang.Thread.run(Thread.java:662)
其中看到"Attach Listener" daemon prio=10 tid=0xb41d7c00 nid=0x606 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
这行，最前变的"Attach Listener" 是线程名， 紧跟其后的 daemon是线程的守护状态，
其中主线程不是daemon的，
"main" prio=10 tid=0xb6d05000 nid=0x5ea runnable [0xb6ee9000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x871644a8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at org.apache.catalina.core.StandardServer.await(StandardServer.java:431)
at org.apache.catalina.startup.Catalina.await(Catalina.java:676)
at org.apache.catalina.startup.Catalina.start(Catalina.java:628)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
在"main" 后没有daemon，看到这样的线程状态，：）
找到问题的根源后，我们可以这样处理：
1.将应用自己创建的线程、timer、scheduler这类的资源设为守护线程（daemon）。setDaemon(boolean on)方法可以方便的设置线程的Daemon模式，true为Daemon模式，false为User模式。
2.自己管理非守护线程的生命周期，当容器停止时手工释放资源。比如你可以在 Servlet 或 ServletContextListener 的 init 方法中初始化资源，在 destroy 方法中释放资源。
编辑回复