加速测试过程

05-01-05 blues
问题现象是:一个java进程,跑着跑着又死了,怀疑是线程死锁.问题是这个问题不是很经常出现,怎么办?

先抛开这个问题究竟是怎么出现的,这个问题总会解决.我想总结一下遇到这样的问题时该怎么办.

实际上,象java常驻程序,常见问题1是线程死锁,2是内存泄漏,解决起来并不困难,如之前的那篇文章所说.

为了解决这个问题,就要先让这个问题能尽快的被模拟出来.所以需要写个模拟压力测试的程序,模拟发送大量的数据包,从而加快问题出现的频度.

从这个问题引发的一个想法,就是:如何保证一个服务能7*24不间断执行.我觉得有一个做法,是在java进程外写一个watchdog,使用shell或者c语言,但不要使用java了,让它不断去嗅探java服务的可用性,不行的话就重新启动java.

这个解决方法看起来很丑陋,但在问题被真正解决之前,似乎没有更好的办法.能解决问题的方法就是好方法.我在元旦时看到家门口的发廊边多了个安全套发放机,觉得很有感触:俺们国家在抓嫖娼,但在嫖娼这个现象消除之前,怎么能避免aids的扩张,一个务实的做法就是:推荐你嫖娼时使用安全套.这个想法和软件中的安全机制很相同:我不允许你错,但是万一你错了,我也要保证你不要出大漏子.

从安全套问题又想到问题的另一方面,就是:关于报表的做法.报表目前的做法是:与核心系统无关,仅仅是共享一个数据库.大家都从数据库中读数据,各不相干.在报表完全集成到核心系统之前,这种做法简直太棒了.对于扩展其他子系统也适用.其解决方案的本质在于:隔离不同的部件.与安全套问题有相似之处(扫黄部门与防aids部门都围绕嫖客这个数据库而展开工作).

说道"隔离不同的部件",回到design pattern中的一些基本原则了,"接口隔离","针对接口编程".fascade模式的作用是隔离子系统."把职责划分清楚",责任到位,这是设计的一个基本原则,带来的一个好处就是避免灾难的无限蔓延.

说道"避免灾难的无限蔓延",又想到java中异常的处理.

说到java,又想到了corba实现java与c的协作机制.哈哈.就先摆到这吧.

banq
2005-01-20 14:03
有意思,其实Java世界真是很现实世界很相似,设计开发一个Java系统,类似创造新世界的感觉,道理很类似。

关于“java进程,跑着跑着又死“的问题,个人觉得还是这个Java进程处理任务过于繁重,可以将其中工作分解,分解成多个线程来完成。使用一个监察者的方式是迫不得已为之。

使用Optimzeite这样的调试工具去监察线程,如果你的系统中占据CPU50%的工作量集中在一个线程或一个类上,说明设计的问题,没有达到细分原则。

只是建议。

猜你喜欢