我一直在我的开发环境上运行Glassfish 4
Windows
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
一切都很完美。
上周，我部署到一个Debian Linux服务器上运行：
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
在Linux环境中运行时，应用程序会间歇性崩溃。它已经运行了好几天没有发生故障，然后在几个小时内坠毁了好几次。当它崩溃时，glassfish或jvm日志文件中没有错误消息，进程就会消失，在一种情况下，jvm日志中包含一行被截断的内容。到目前为止，我发现的唯一线索是syslog和userlog包含：
grepjava*
syslog:Jan 14 13:41:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb6ac076730 ***
syslog.1:Jan 13 19:48:04 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb037835c90 ***
user.log:Jan 13 19:48:04 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb037835c90 ***
user.log:Jan 14 13:41:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb6ac076730 ***
user.log.1:Jan 8 10:19:30 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x0000000007974a90 ***
user.log.1:Jan 8 14:29:11 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00000000082431f0 ***
user.log.1:Jan 8 14:57:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007f805f87f490 ***
user.log.1:Jan 8 18:23:42 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007eff39829ca0 ***
除了结尾的地址外，所有的错误看起来都是一样的。所有的时间都对应于服务器崩溃的时间，所以这似乎是服务器消失的原因。
所讨论的应用程序是一个文档存储系统，它接受多种格式的文档并将其存储在MongoDB中。在可能的情况下，它还将图像渲染为JPG格式。
它使用Apache PDF Box和Java Advanced Imaging来渲染JPG。它运行Spring Framework、SpringData MongoDB和Spring Security。它偶尔会使用jtd访问数据库，但这种情况并不常见，而且我很确定在崩溃时没有发生数据库活动。图像再处理是最近发生的，但在大多数崩溃时都成功完成了(没有对所有图像进行验证，但对最近的崩溃进行了详细验证，并且为最近保存的文档生成并保存了每个图像)。崩溃发生在上传最新文档50秒后。
事实上，我在网上发现的所有讨论都是用C或C++程序进行的，这在那里是有意义的。不过，我能想到的在Java程序中发生这种情况的唯一方法是通过JNI(我没有使用它，也许我使用的一些库可以进行JNI，但如果是这样，我不知道)或JVM错误。
有人对缩小造成这个问题的原因有什么建议吗？
我可以打开任何日志记录或诊断来获取更多详细信息吗？
目前，我唯一能想到的就是在关闭某些功能的情况下运行应用程序一段时间(目前我最怀疑使用PDF Box渲染PDF)，看看哪些功能组合是稳定的，哪些不是。如果可能的话，我宁愿有一个更明确的方法(而且不需要等几天看测试是否有效！)。
您可以尝试安装Oracle的"官方"二进制文件，关于如何为Ubuntu安装的指导可以在这里找到。它使用update-alternatives，这是一个Debian工具，因此将在Ubuntu中提供，以指向Oracle JRE安装。