这里有点奇怪，我们正在我们的一个应用程序（在 IBM 64 位 JVM 中）中运行 Dozer (5.3.2)。上周五，由于 JVM 发出一般保护错误，我们的一个生产机器突然停止。不幸的是，我们没有任何有用的日志记录来向我们展示当时发生的事情，但是 JVM 的 javacore 文件表明问题是在 Dozer 的 DozerBeanMapper 中执行代码时发生的：
1XMCURTHDINFO Current thread
NULL ----------------------
3XMTHREADINFO "WebContainer : 70" J9VMThread:0x0000000011B1C600, j9thread_t:0x00002AAAC4F95920, java/lang/Thread:0x000000012D92E198, state:R, prio=5
3XMTHREADINFO1 (native thread ID:0x6BE2, native priority:0x5, native policy:UNKNOWN)
3XMTHREADINFO2 (native stack address range from:0x00002AAAC2CD4000, to:0x00002AAAC2D15000, size:0x41000)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at org/dozer/DozerBeanMapper.getMappingProcessor(DozerBeanMapper.java:184)
1INTERNAL Unable to walk in-flight data on call stack
我快速查看了 DozerBeanMapper 的 Dozer 源代码，并注意到javacore 日志中报告的代码行使用了 Sun 的java.util.concurrent.atomic.AtomicBoolean，它本身使用sun.misc.Unsafe。根据对它的理解，sun.misc.Unsafe它允许比 JVM 通常公开的更直接和任意的内存分配功能。我当然在这里推测，但这让我想知道我们看到的 gpf 是否可能与 Dozer 使用sun.misc.Unsafe.
不幸的是，我们在应用程序中使用了多个 DozerBeanMapper 使事情变得更加复杂（我们正在努力解决这个问题……继承代码不是很有趣吗）。这些映射器至少只在应用程序启动时实例化一次，而不是在每个请求的基础上。
不幸的是，我还没有弄清楚如何复制这个问题，所以我想在尝试这样做的同时收集一些信息，因为我目前正在努力思考如何证明/反驳我的理论。有没有其他人在使用 Dozer 时遇到过任何 gpf 情况？我们使用多个 DozerMapperBeans 是否可能导致问题？
感谢任何想法，
埃德