java-宕机-zip-多线程操作zip（同名）文件导致HotSpot崩溃

项目名称：alipay-web
问题表现：服务经常存在无故宕机情况。
抓取参考日志：

• 参见files/hs_err_pid28588.log
• 参见files/hs_err_pid46891.log
• 参见files/catalina.out-20160926

如上文件均在

经日志分析：发生此问题的时间一般在早晨9点17分左右，抓取日志分析

提现业务导致，而此时间正好是支付宝批量提现业务通知时间，日志指出与解压zip文件相关。

思路与问题：

1. java虚拟机崩溃，经常是内存泄露导致的，从程序级别需要检查内存泄露情况。
   此问题通过Hotspot日志可以排除抓取部分 日志分析：

Survivor from存在垃圾，经过垃圾回收新生代区域不在存有数据，老年代增加了19k 可以判断此次肯定是新生代垃圾回收（并且full 656没有变化也可以判断），并且回收率较高，初步判断是Survivor区多次交换后进入了老年代，并且老年代object使用率很低只有14%。判定最后一次gc为正常高效gc，系统暂时不存在内存泄露。

2. 再次回到Hotspot的起初的日志。

最底层的c部分抛出的异常，并且存在SIGBUS (0x7)的指示。
SIGBUS 即为bug error 一般原因为：
CPU处于性能方面的考虑，要求对数据进行访问时都必须是地址对齐的。如果发现进行的不是地址对齐的访问，就会发送SIGBUS信号给进程，使进程产生 core dump。RISC包括SPARC（一种微处理器架构）都是这种类型的芯片。x86系列CPU都支持不对齐访问，也提供了开关禁用这个机制。x86架构不要求对齐访问的时候，必定会有性能代价。例如，对int的访问应该是4字节对齐的，即地址应该是4的倍数，对short则是2字节对齐的，地址应该是2的倍数。
也就是SIGBUS(Bus error)意味着指针所对应的地址是有效地址，但总线不能正常使用该指针。通常是未对齐的数据访问所致。

百度搜索：http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8139766
快照：

英文不好，大致的意思是做zip操作的时候会把文件读进map容器，但是在jdk没有很好地控制文件变化后的处理（理解为文件句柄没被释放的时候文件再次变化后出现此问题）。
意思很明确了，也就是在处理zip文件的时候，如果文件又被改变了，便会引起崩溃，虽然终归是jdk的bug但是为什么会出现解压的同时文件再次被改变？
经查代码（摘取代码片段如下）

系统是用一个到yyyyMMddHHmm精确到分的文件名收取的，如果系统在一分钟多次收到zip文件，会出现什么情况。
问题已经找到，经过验证确实是此处问题崩溃测试也得到复现。
最终修改方式精确到毫秒并加入4位随机值