trtrtg的专栏

其次，从第三步“检查运行时堆栈情况”中发现DC、BMS、DMS定时任务线程都blocked在打印cmd控制台这块，打印cmd控制台是一个串行操作，也就是java应用程序中的所有线程都是排队打印cmd控制台的，当cmd出现性能问题时就会导致所有的线程等待，不管是定时任务线程还是web请求线程，web请求线程代表的是用户界面的操作，所以会出现页面缓慢、卡死的情况。五一没有出现卡顿情况”。当cmd出现卡死后，接着重启进行下一次，经过6、7次测试，每次正常运行的5分钟内、10分钟内、30分钟内不等，结果都会卡死。

​ 有个客户，项目组报他们家的测试环境很卡，解决不了，于是我介入处理。

也检查了141服务器的socket限制，为6.3W。通过同事了解到上次重启时 间有半月，也就是半月产生了6.3W的socket创建请求，“socket设置过小”这种假设不合理，更多的像是使用不合理导致。

​ 不是linux中的top，而使用topas命令，发现all CPU占用73%多，头两个进程占了73%，而通过ps -ef |grep java对比进程信息发现头两个进程是非本公司产品进程。再切到"内存泄漏"页，按箭头方向向下推理，找到可疑堆栈，如图，其中某个对象有2.3万对个，判断为这个堆栈查询了至少2.3万多个对象，可能还没执行完就崩溃了。​ 在一些老的财务系统中，仍然使用的是IBM的硬件及它的操作系统AIX，本次熟悉aix基本检查操作以及aix下的java出现内存溢出时如何操作。

​ 客户A的Bcp-server服务配置了JFR，在事发后重启域，仍然能够快速精准解决CPU问题，可有效提高客户满意度。因此强化监控是每个项目实施时的必备工作。

但这个是过程是渐渐的：刚开始failover心跳没问题、后来出现连接不上或读超时问题、再后来业务出现问题导致无法回调执行结果，也就是执行结果是“处理中”，最后业务节点也无法上报自己的配置心跳信息（xxl_job_registry）,这就是为什么任务调度时间从14:50多开始到执行结束时间17:05分之间（执行结束是由JobCompleteHelper找从调度开始超过10分钟的还在处理中的，并且服务不上报心跳了）有这么长的时差。能返回，但是业务等其他操作无法继续，如果选择这个地址，那业务任然无法执行。

这些表的更新操作有锁是等待很正常的。结合之前文档中描述的超时的相关请求，查看了这些请求的代码，发现代码模式基本是FOR->sql，即可能会产生大量的SQL；(1) 14日57错误偏向问题，经查证，9点多同一时间段从总线程量从400多激增到600多，而56基本维持在400多，这高峰期请求量必定是WEB请求，并全部打到了57，导致了57异常。日志乱序的原因是生成日志对象后，log4j框架使用JAVA syn关键字同步了写日志，而因为syn同步是不排序的，先到的不会先打，所以日志文件中日志消息是乱序的。

XXJobTrigger方法执行与外层的调用者XXJobScheduleHelper调度器的scheduleUpdate方法（更新调度状态）不在一个线程、一个事务里面，导致内层的loadId报错了，业务还未执行，但调度状态确已持久化，调度状态决定了下次执行时间。其次，通过查看数据库xxl-job执行日志，发现132处理了大部分任务，131承担了小部分任务，而18日的10:30定时任务轮给131执行，排除压力问题导致131执行异常。进而怀疑131执行少的原因依旧是大量的“连接不可用”异常导致；

SSL JDK加密套件问题导致服务器响应空白