复杂的故事简单说，复杂的问题简单做。
现象
1：应用部分功能只要一访问就重启。
2：每一次重启在was安装目录下产大批量文件,主要4类：core.*.dmp,javacore,gc和trc文件
关键点
重启、core.dmp、javacore、trc。
分析
- 注意core.dmp
1. core.dmp文件大，每个都有1.5G，有些会接近2G，及时删除，避免文件空间爆满。
2. core.dmp 区别于可分析的 headump.phd文件，是不能用“IBM Thread and Monitor Dump Analyzer for Java”分析的文件，core.dmp是当前进程的内存情况，当前进行消耗了多大内存，这个文件就对应多大，是操作系统进行的内存快照，文件大，也没有实际的分析价值，可以分析一下javacore文件。
- javacore 文件
javacore文件网上分析的贴子多，这么不描述，对于JDK问题的情况多半会抛一些中间价或JDK的类目录和一些说明在Note的地方，可以重点注意这一块。javacore可以用“IBM Thread and Monitor Dump Analyzer for Java”分析，也可以用文本编辑器简单打开看看。
“IBM Thread and Monitor Dump Analyzer for Java”工具的使用：
JCA
- 漫长分析
最漫长的定位过程就是排除法，修改代码，找出其中一处导致服务重启的代码，而且是JDK原生的方法，结合产生core.dmp文件基本就可以判断为JDK有问题。
如果产生了core*.dmp文件可以直接替换下JDK试试，直接替换JDK相对于漫长的代码分析效率更高。
处理方法
- 拷贝JDK:
找一台安装了同版本was或同版本JDK的服务器（也可以直接在网上下载同版本JDK来安装），登陆远程服务器，使用scp 复制一份jdk到有问题的机器。
例如:有问题的机器IP为192.168.22.10，令一台机器为192.168.22.11，账号为was,登陆192.168.22.11，使用命令：scp -r /was/AppServer/java was@192.168.22.10:/was/AppServer/java_2，此时，在10机器就有了一个新的java，文件夹是java_2
- 配置新JAVA_HOME:
登陆was控制台，“环境--WebSphere变量--JAVA_HOME”，修改路径为到新的java.
- 重启服务
重启Server，检查是否正常。
后记
严防：严防对JDK的文件替换和删除操作，JDK一个点的修改对应用的影响可能特别大。
简单应用，希望对你有用。
<small>笔者问题处理环境:was6升级到was7，JDK1.5升级到JDK1.6，是新环境的JDK1.6有问题，定位问题后替换JDK1.6，问题解决。</small>
