前言

好好运行的系统，突然故障，无意间根据错误信息查找，竟然是jdk的bug，描述下曲折的定位过程。

1、错误日志

有个老系统有使用到soap接口，采用CXF结合接口文件wsdl自动生成的接口开发的，突然在3月2日（后续日志定位才发现真正故障的时间）无法正常工作，但是实际发现时间已经到了3月6日了，直接查看日志文件，报错“组装saop报文头异常:Entity References are not allowed in SOAP documents”

想到看看是不是代码做了什么改动，进svn版本管理工具对比，没有改动，最近一次部署是在3月5日上午，3月2日周六突然就故障了，属于突发性异常，感觉可以排除自身的问题，然后去咨询服务端系统，对方说也没有任何改动，现在才接手，不可能进行新的开发。

但是接口一直在日志中打印错误，对比svn提交记录，发现确实没人改动代码，难道是对方动了代码？

抱着这种心态总觉得是服务端异常了。

2、检查代码和修改记录

有了这个排除自己代码改动造成异常的前提后，始终觉得是服务端异常了，然后通过抓包对比正常接口、异常接口，SoapUI发送，重现错误返回值等一系列对比，3月6、7日没有任何结果，唯一发现就是报错的接口没有soap请求没有head信息，只有UTF-8的字符集和body，这种结构就有些奇怪了，难道是鉴权账号被锁？

继续用soapUI测试这个账号，其他接口跑起来正常，修改了一条数据返回是success，更加郁闷了，怎么可能head平白无故丢失呢？

3、继续啃问题

继续啃这个问题，因为有数据堵住了，慢慢积压越来越多，这样下去迟早会造成更大的失误。

问题还是要继续解决，只好重新打包个测试包，去测试环境对接soap服务端，下个订单，查看日志和抓包，查看接口推送的请求，测试环境验证正常，说明代码OK，抓包查看xml报文，head和body都在。

6、7日的对比把报错的信息复制到百度看看有没查询到类似的案例，结果都是乱七八糟的一堆东西，没什么价值。

4、抛弃baidu用google

6、7号1天半没找到问题，但是又不可以继续拖了，试试google呗，一下眼前一亮，第一条查询就是openJDK的bug库，一直没怀疑jdk的bug，始终认为它是正常的，赶快找到jdk bug库，把关键字放进去一查询，查到结果有个bug单，心里一喜，终于找到问题原因了。

啃了2天半了，终于找到问题的原因了：
OpenJDK bug库: https://bugs.openjdk.java.net/browse/JDK-8196491
OracleJDK bug库: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8196491
stackoverflow bug讨论: https://stackoverflow.com/questions/48603942/latest-open-jdk-8-jaxb-library-fails-to-unmarshal-objects-with-properties-that-c

5、垃圾百度，google有用

这里吐槽下，垃圾百度，以前还可以筛选一些有用的信息，这次白白浪费2天的时间，没有价值的信息一堆，就放弃网上找案例了。

google里面可以找到stackoverflow和openjdk的链接，已经确认jdk1.8.0版本的bug，2018年01月份暴露该bug，2018年04月份修复，修复版本是1.8.0.192。

6、下载新update版本jdk

立马下载最新202 update版本，部署环境，重新，偶然没有出现相同的错了，然后一看时间，已经是3月8日21:30了，继续观察下，确认正常，问题得以修复。

估算堵住的数据，预计还需要36小时才可以处理完，周末时间刚好。这下周末可以轻松下，不用跑来继续啃问题了。

7、附上错误信息截图

OpenJDK的版本错误信息描述：

OpenJDK的错误样例：

业务日志中的错误信息：

业务所在服务器的JDK版本和安装时间：

PS：

有一点是这个jdk跑了这个出bug的业务差不多1年了，为啥这1年不出问题呢？怀疑是header里的鉴权session字符串开始用完纯字母类型的，出现带特殊字符的了，从开始出现特殊字符就触发这个bug