1.出现故障。今天发现服务查询一直卡住了，于是查看服务器：当时就懵了，CPU被这一个服务占用了。再看端口号下：出现了大量的CLOSE_WAIT。看到这里，我只有一个想法：是程序代码有问题，还是配置有问题。2.排查问题为此，我重启了服务，并添加了参数，用jconsole查看服务状态：-Djava.rmi.server.hostname=xxx.xxx.x??xx.xxx-Dcom.sun.management.jmxremote-Dcom.sun.management.jmxremote.port=10000-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false然后打印GC日志：-verbose:gc-Xloggc:/usr/app/ydjAgent/gc_log-XX:+PrintGCDetails-XX:+PrintGCTimeStamps启动参数太长，我加到环境变量中：vim/etc/profileexportJAVA_OPTS='-Xms1024m-Xmx4096m-Djava.rmi.server.hostname=120.0.0.1-Dcom.sun.management.jmxremote-Dcom.sun.management.jmxremote.port=10000-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false-verbose:gc-Xloggc:/usr/app/ydjAgent/gc_log-XX:+PrintGCDetails-XX:+PrintGCTimeStamps'根据jconsoleoverview和GClogs可以看出是因为系统频繁GC导致的：正常情况下情况下，younggc频繁是正常的，但是如果fullgc很频繁，一般问题是接口查询中收集的数据已经保存了，但没有删除，导致gc没有及时回收。然后把堆信息dump出来用Eclipsememoryanalyze分析，发现char[]数组和byte[]数组占了大部分内存。经过上面的分析发现，由于业务需要统计一个月内所有订单中的商品和品牌排名，由于原表设计的主键id是UUID，所以服务只给了最大4G内存。启动时，即使是只查询订单id也占用了很大一部分空间，更何况后面查询的订单信息会占用更多的内存空间，也正因为如此，对数据库和应用程序的压力都会也很棒，应用一直处于FULLGC状态，CPU被完全占用。3、解决方案因为应用和数据库在同一台服务器上，所以先将应用部署到另一台服务器上，然后使用nginx通过内网转发请求，设置内存为8G，缓解原服务器的CPU压力。这样一来，在数据访问的时候还是给数据库带来了很大的压力。因为我的代码太烂了哈哈。.事情发生后，我先向老板汇报，老板表示理解。.给我时间重新设计原来的架构。..更别提写代码了。..
