这里有点好奇，我们在我们的一个应用程序（在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源代码，发现line of code which is reported in the javacore log使用了Sun java.util.concurrent.atomic.AtomicBoolean本身使用sun.misc.Unsafe的{{3}}。从对sun.misc.Unsafe的理解来看，它允许比通常由JVM公开的更直接和任意的内存分配功能。我当然在这里推测，但这让我想知道我们看到的gpf是否与Dozer使用sun.misc.Unsafe有关。
为了进一步复杂化，我们不幸在我们的应用程序中使用了多个DozerBeanMappers（我们正在努力修复......继承代码并不是很有趣）。这些映射器至少在应用程序启动时而不是按请求实例化一次。
不幸的是，我还没有弄清楚如何复制这个问题，所以当我尝试这样做时，我会收集一些信息，因为我正在努力思考如何证明/反驳我的理论。有没有其他人在使用Dozer时遇到任何gpf情况？是否可能我们使用多个DozerMapperBeans导致了这个问题？
感激任何想法，
埃德