我在生产服务器上发生JVM崩溃。它在/tmp/jvm-32627/hs_error.log中生成了一个日志。文件的开头是：
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f4cdd7fba55, pid=32627, tid=139964606174976
#
# JRE version: OpenJDK Runtime Environment (7.0_79-b14) (build 1.7.0_79-mockbuild_2015_07_24_09_26-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.79-b02 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.5.5
# Distribution: CentOS release 6.6 (Final), package rhel-2.5.5.4.el6-x86_64 u79-b14
# Problematic frame:
# V [libjvm.so+0x610a55]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
--------------- T H R E A D ---------------
Current thread (0x00007f4b1b90c000): JavaThread "Java2D Disposer" daemon [_thread_in_vm, id=33107, stack(0x00007f4c0c91d000,0x00007f4c0ca1e000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
Registers:
RAX=0x0000000000000000, RBX=0x00007f4b1b90c000, RCX=0x00007f4c0ca1c480, RDX=0x00007f4cddfe11a0
RSP=0x00007f4c0ca1c450, RBP=0x00007f4c0ca1c4e0, RSI=0x00007f4b1b90c000, RDI=0x00007f4c0ca1c480
R8 =0x00007f4c0ca1c490, R9 =0x0000000000000000, R10=0x00007f4cddfd7ef8, R11=0x0000000000000002
R12=0x00007f4b1b90c1d8, R13=0x00007f4b6c12d850, R14=0x00000000000000c2, R15=0x0000000000000000
RIP=0x00007f4cdd7fba55, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f4c0ca1c450)
0x00007f4c0ca1c450: 00007f4b1b90c000 00007f4c001c3758
0x00007f4c0ca1c460: 00007f4c0ca1c470 00000000000000c2
0x00007f4c0ca1c470: 00007f4b1b90c000 00007f4c0ca1c480
0x00007f4c0ca1c480: 00007f4b1b90c000 0000000000000000
0x00007f4c0ca1c490: 0000000000000004 00007f4c001c37a8
0x00007f4c0ca1c4a0: 00007f4b1b90c000 523beb0a00000001
0x00007f4c0ca1c4b0: 00007f4b6c12d850 00007f4b1b90c1d8
0x00007f4c0ca1c4c0: 00007f4b6c0bc320 00007f4b6c12d850
0x00007f4c0ca1c4d0: 00007f4b6c054f40 00007f4b1b90c000
0x00007f4c0ca1c4e0: 00007f4c0ca1c500 00007f4c0c0cbe31
0x00007f4c0ca1c4f0: 00007f4b6c12d930 0000000000000001
0x00007f4c0ca1c500: 00007f4b6c12d6a0 000000358b610f17
0x00007f4c0ca1c510: 00007f4b6c04fc90 00007f4b6c12d6a0
0x00007f4c0ca1c520: 000000358b89b6e0 000000358b6119d4
0x00007f4c0ca1c530: 00007f4b6c12d6a0 00007f4b6c04fc90
（堆栈继续运行2000行左右...）
JVM是IcedTea 2编译版（OpenJDK 1.7.0_79），正在执行Tomcat 7，并且在CentOS 6.6（Linux 2.6.32-573.el6.x86_64内核）上运行。
经过一些研究，似乎Java2D Disposer线程是一个用于释放Java2D和AWT所使用的本机资源的线程，这些资源不是由GC管理的。我不明白为什么JavaEE服务器会对其进行修饰...
我们昨晚发生了崩溃，但调查显示，它很可能是2017年10月的第一次崩溃和2018年3月的第二次崩溃。在6或8个月内发生一次崩溃可以被认为是可以接受的，但该系统对于业务至关重要（甚至如果确实存在如此多的错误，难闻的代码，旧版本的库和工具等等，那么……），我真的很想摆脱这个问题。
通常，我们应该有一个核心转储，但是核心转储当然已经被禁用了，所以我们什么也没有。
有人知道发生了什么以及如何解决？