ClientEncryption Java 11.0.10+9 Red Hat不支持单例模式，断断续续地在tcache中检测到双空闲

Question

free（）：在tcache2中检测到双空闲Java运行时环境检测到一个致命错误：

SIGSEGV(0xB)在pC=0x00007F3E214FBD21,PID=1,TID=91处

JRE版本：OpenJDK Runtime Environment 18.9(11.0.10+9)（构建11.0.10+9-LTS)Java VM:OpenJDK 64位服务器VM 18.9(11.0.10+9-LTS，混合模式，共享，分层，压缩oops，g1 gc，linux-amd64)问题帧:C[libc.so.6+0x21d21]中止+0x203

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

如果您想提交bug报告，请访问:https://bugzilla.redhat.com/enter_bug.cgi？product=red%20hat%20enterprise%20linux%208&component=java-11-openjdk崩溃发生在Java虚拟机之外的本地代码中。有关报告bug的位置，请参见problematic frame。

JRE构建版本是11.0.10+9-LTS（OpenJDK Runtime Environment RedHat）OpenJDK 64位服务器VM 18.9(11.0.10+9-LTS，混合模式，共享，分层，压缩oops，g1 gc，Linux-amd64我使用spring boot with spring data JPA,

我从日志中观察到，每当我的应用程序打开到mongo的连接时，它都会在这个JVM CRACH上着陆。

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崩溃。

Answer 1

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

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

对于clientEncryption的新对象，它工作得很好，但是这个解决方案带来了一个更严重的问题，即在加密和解密数据时系统速度慢。