1700450209
1700450210
有了这两点，TcpServer就可以稳定地运行了，即使出现异常也能自动重启。客户端代码比较简单，只需要new TcpServer（）即可，运行结果如下：
1700450211
1700450212
系统正常运行：0
1700450213
1700450214
系统正常运行：1
1700450215
1700450216
系统正常运行：2
1700450217
1700450218
线程Thread-0出现异常，自行重启，请分析原因。
1700450219
1700450220
java.lang.RuntimeException
1700450221
1700450222
at TcpServer.run（Client.java：30）
1700450223
1700450224
at java.lang.Thread.run（Thread.java：619）
1700450225
1700450226
系统正常运行：0
1700450227
1700450228
系统正常运行：1
1700450229
1700450230
系统正常运行：2
1700450231
1700450232
线程Thread-1出现异常，自行重启，请分析原因。
1700450233
1700450234
java.lang.RuntimeException
1700450235
1700450236
at TcpServer.run（Client.java：30）
1700450237
1700450238
at java.lang.Thread.run（Thread.java：619）
1700450239
1700450240
从运行结果上也可以看出，当Thread-0出现异常时，系统自动启动了Thread-1线程，继续提供服务，大大提高了系统的可靠性。
1700450241
1700450242
这段程序只是一个示例程序，若要在实际环境中应用，则需要注意以下三个方面：
1700450243
1700450244
（1）共享资源锁定
1700450245
1700450246
如果线程异常产生的原因是资源被锁定，自动重启应用只会增加系统的负担，无法提供不间断服务。例如一个即时通信服务器（XMPP Server）出现信息不能写入的情况时，即使再怎么重启服务，也是无法解决问题的。在此情况下最好的办法是停止所有的线程，释放资源。
1700450247
1700450248
（2）脏数据引起系统逻辑混乱
1700450249
1700450250
异常的产生中断了正在执行的业务逻辑，特别是如果正在执行一个原子操作（像即时通信服务器的用户验证和签到这两个事件应该在一个操作中处理，不允许出现验证成功但签到不成功的情况），但如果此时抛出了运行期异常就有可能会破坏正常的业务逻辑，例如出现用户认证通过了，但签到不成功的情况，在这种情景下重启应用服务器，虽然可以提供服务，但对部分用户则产生了逻辑异常。
1700450251
1700450252
（3）内存溢出
1700450253
1700450254
线程异常了，但由该线程创建的对象并不会马上回收，如果再重新启动新线程，再创建一批新对象，特别是加入了场景接管，就非常危险了，例如即时通信服务，重新启动一个新线程必须保证原在线用户的透明性，即用户不会察觉服务重启，在此种情况下，就需要在线程初始化时加载大量对象以保证用户的状态信息，但是如果线程反复重启，很可能会引起OutOfMemory内存泄露问题。
1700450255
1700450256
1700450257
1700450258
[
上一页 ]
[ :1.700450209e+09 ]
[
下一页 ]