最近有几次刚部署几分钟线上后，出现某个地址无法响应。查看浏览器提示。由于是线上环境，不能停太久，重启应用后基本上可以访问。
provisionalheadersareshown
这次由于是晚上，客户基本上不需要使用，可以借这个时机好好分析。分析后大致原因是请求超时，后端不响应。系统使用的是nginx转发tomcat。直接使用ip地址访问，仍有该提示，因此和nginx没有太大关系。
继续排查考虑会不会是数据库死锁导致。使用的是mysql，登陆数据查看锁情况。没有死锁语句。
// 查看进程
SHOW PROCESSLIST;
// 查看是否锁表
SHOW OPEN TABLES WHERE In_use > 0;
// 查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
// 查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
继续查看系统负载，也没有什么压力。
top
继续查看系统进程，发现几个系统的代码一直在执行。
//查看tomcatjava进程
ps aux | grep java
//使用堆栈跟踪工具jstack导出当前系统的进程执行情况
jstack 28174 > dump.txt
查看代码，集中在几个代码内。
atxxx.isOpen(xxx.java:132)orderAddSave(xxx.java:1017)
分析代码，集中在一个类中，全部访问一个公共静态HashMap对象。该对象访问量较大，且启动时会存在初始化插入和更新的情况。大致问题已经确认了，HashMap多线程下造成的程序死锁。
解决方法：
1：Hashtable替换HashMap
访问量大会造成异常。
2：Collections.synchronizedMap将HashMap包装起来
不遵从此建议将导致无法确定的行为。如果指定映射是可序列化的，则返回的映射也将是可序列化的。
3：ConcurrentHashMap替换HashMap（建议）
完美解决上面两个顾虑，建议采用。
,
