首页 > 解决方案 > ClientEncryption 不支持单例模式 |Java 11.0.10+9 Red Hat,在 tcache 中间歇性检测到双重释放

问题描述

我在运行 12-13 小时后,运行 JVM 的 Azure pod 崩溃并出现以下错误的情况下运行

free(): double free 在 tcache 2 中检测到 Java 运行时环境检测到致命错误:

SIGSEGV (0xb) 在 pc=0x00007f3e214fbd21,pid=1,tid=91

JRE 版本:OpenJDK Runtime Environment 18.9 (11.0.10+9) (build 11.0.10+9-LTS) Java VM:OpenJDK 64-Bit Server VM 18.9 (11.0.10+9-LTS,混合模式,共享,分层,压缩的 oops,g1 gc,linux-amd64)有问题的帧:C [libc.so.6+0x21d21] abort+0x203

将写入核心转储。默认位置:可以使用“/usr/share/apport/apport %p %s %c %d %P %E”处理核心转储(或转储到/home/jboss/core.1)

包含更多信息的错误报告文件保存为:/home/jboss/hs_err_pid1.log

如果您想提交错误报告,请访问: https ://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&component=java-11- openjdk 崩溃发生在 Java 之外本机代码中的虚拟机。请参阅有问题的框架以了解报告错误的位置。

JRE 构建版本为 11.0.10+9-LTS(OpenJDK Runtime Environment RedHat) OpenJDK 64-Bit Server VM 18.9 (11.0.10+9-LTS, 混合模式, 共享, 分层, 压缩 oops, g1 gc, Linux-amd64 I我正在使用带有弹簧数据 JPA 的弹簧靴,

每当我的应用程序打开与 mongo 的连接时,我都会从日志中观察到它在这个 JVM 裂缝上的土地。

2021-05-05 07:36:29.512 DEBUG 1 --- [nio-8090-exec-1] c.xxx.xx.xx.SectionHandlerService        [db340496-d1fb-43f0-92c9-f7114194dfbf] : questionnaire  extracted with Id :: 4308655
2021-05-05 07:36:29.512 DEBUG 1 --- [nio-8090-exec-1] com.xxx.utils.MapperUtil               [db340496-d1fb-43f0-92c9-f7114194dfbf] : mapToModel Started
2021-05-05 07:36:29.512 DEBUG 1 --- [nio-8090-exec-1] com.xxx.utils.MapperUtil               [db340496-d1fb-43f0-92c9-f7114194dfbf] : Converting com.xxx.xxx.entity.Section To com.xxx.xxxxx.SectionModel class using mapToModel
2021-05-05 07:36:29.623  INFO 1 --- [nio-8090-exec-1] org.mongodb.driver.connection            [db340496-d1fb-43f0-92c9-f7114194dfbf] : Opened connection [connectionId{localValue:266, serverValue:267840}] to xxxxxxxxxxxxxx:27017

在我的最后一条语句(即打开连接)之后,我的应用程序着陆到 JVM 崩溃。

现在我需要了解我使用的 java mongo 驱动程序是否有问题,一旦应用程序打开 mongo 连接,pod 就会重新启动,并出现上述 JVM 错误。

很难产生这个问题。如果我们的应用程序在满负载情况下运行正常,并且如果我们在理想时间 12 小时后运行应用程序,我们就会陷入这个 JVM 崩溃。

标签: javamongodbspring-bootspring-data-jpa

解决方案


找到了解决方案。这不是 JVM 的问题,而是mongo-driver-sync库的问题。clientEncryption 对象的单例对象创建导致 JVM 在经过一定的理想时间后崩溃。

在我们的例子中,一旦我们启动应用程序并进行了一些加密,它就可以正常工作,但是在一段时间后,如果我们保持应用程序理想,然后尝试使用相同的单例实例进行加密,那么 JVM 就会崩溃。

使用 clientEncryption 的新对象,它工作正常但是这个解决方案在加密和解密数据时系统缓慢方面带来了更严重的问题。

提高了Mongo Ticket的票 让我们看看他们会有什么解决方案


推荐阅读