在多线程上下文中使用Spring和生菜的OutOfDirectMemoryError

Question

我们使用spring-data-redis和spring-cache抽象以及lettuce作为我们的redis客户端。此外，我们还在一些方法上使用多线程和异步执行。

--一个示例工作流应该如下所示：

Main-Method A(主线程) -->调用方法B (@Async)，它是一个代理方法，可以在另一个线程中异步运行逻辑.->方法B调用方法C，即@Cacheable。@Cacheable注释处理对红缓存的读/写。

，怎么了？

Lettuce是Netty-based，它依赖于DirectMemory。由于程序的@Async特性，我们同时有多个线程使用LettuceConnection (因此也是Netty)。

通过设计，所有线程都将使用相同的(?) Netty，它共享DirectMemory。由于MaxDirectMemorySize太小，当太多线程访问Netty时，我们会得到一个Netty。

示例：

io.lettuce.core.RedisException: io.netty.handler.codec.EncoderException: io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 8388352 byte(s) of direct memory (used: 4746467, max: 10485760)

到目前为止我们发现了什么？

我们使用https://docs.cloudfoundry.org/buildpacks/java/，使用https://github.com/cloudfoundry/java-buildpack-memory-calculator计算MaxDirectMemorySize。

这是利兹到一个MaxDirectMemorySize=10M。实际可用内存为4GB，计算出的MaxDirectMemorySize可能是保守的方法。这可能是问题的一部分。

问题的势解

sufficent

• configure ->
• 会增加JVM ->的MaxDirectMemorySize，但我们不确定是否Netty不使用DirectMemory (noPreferDirect=true) -> Netty将使用堆，但是如果Netty太渴望内存

H 142不知道这是否是一个选项，甚至使问题变得更糟:将Lettuce配置为d44/code>->这将导致对redish 245/code>F 246的多个连接，则会导致应用程序过于缓慢，则会导致不安全。

我们的问题是:我们如何正确地解决这个问题？

我将很高兴地提供更多关于我们如何设置应用程序配置(application.yml、LettuceConnection等)的信息，如果其中任何一个都有助于解决问题的话。

Answer 1

感谢在：https://gitter.im/lettuce-io/Lobby的工作人员，我们获得了一些关于如何处理这些问题的线索。

正如所怀疑的那样，考虑到可用内存总量，10M MaxDirectMemorySize太保守了。

建议增加这一价值。由于我们实际上不知道Netty需要多少内存才能执行更稳定的操作，所以我们考虑了以下步骤。

First:我们将通过设置noPreferDirect=true来禁用Netty对MaxDirectMemory的偏好，然后Netty将使用堆缓冲区。

第二步：，然后我们将监视在操作期间Netty将消耗多少堆内存。这样，我们就可以推断出Netty的平均内存消耗。

第三步：我们将获得平均内存消耗值，并将其设置为“新的”MaxDirectMemorySize，方法是在-XX:MaxDirectMemorySize选项中设置它。然后，我们将通过设置Netty来重新启用DirectMemory。

第四：监视器日志条目和异常，看看我们是否还存在问题，或者这是否成功了。

UPDATE我们从前面提到的步骤开始，但是意识到设置noPreferDirect=true并不能完全阻止netty使用DirectMemory。对于某些用例(Nio)，Netty仍然使用DirectMemory。

所以我们不得不增加MaxDirectMemorySize。

现在，我们设置以下JAVA_OPTS -Dio.netty.noPreferDirect=true -XX:MaxDirectMemorySize=100M。这可能会解决我们的问题。