希望我已经在这里了解了所有混乱的细节，这有点微妙。
默认情况下，如果可能的话，Netty 通常会设置io.netty.maxDirectMemory=MaxDirectMemorySize并启用“无清理器”缓冲区。如果使用“无清理”缓冲区，Netty 的直接内存和 Java 的“本机”直接内存将被独立跟踪——因为 Netty 需要自己进行统计来跟踪Unsafe.allocateMemory“无清理”缓冲区中分配的内存。
这意味着在运行默认配置的 Netty 服务中为堆外数据预留的理论最大内存通常是粗略的io.netty.maxDirectMemory+MaxDirectMemorySize——或者2 x MaxDirectMemorySize默认情况下。这是在这里悄悄记录的：
所以这很好，即使有点令人惊讶。
但是，当您尝试将 io.netty.maxDirectMemory 和 MaxDirectSize 显式设置为不同的值时，事情似乎变得有点奇怪。例如，我们试图稍微压低理论上的内存上限，以便与 cgroup 良好配合：相关服务正在被 OOM 杀死，因此我们变得有点激进，一旦我们意识到 MDMS/inmdm 之间的关系，就设置 MaxDirectMemorySize和 io.netty.maxDirectMemory 显式地最小化我们的上限 --XX:MaxDirectMemorySize=1g并设置-Dio.netty.maxDirectMemory=3221225472启用“无清理”直接缓冲区。
我预计就 Netty 而言，这实际上是一个无操作更改，因为我们在-XX:MaxDirectMemorySize=3g明确设置io.netty.maxDirectMemory. 然而，我们观察到报告的正在使用的直接内存大大减少。怀疑这可能与减少 MaxDirectMemory 大小有关，我最终发现了这一点，我认为这可以解释其中的差异。
为什么使用PlatformDependent.maxDirectMemory()here（它将被设置为 的值MaxDirectMemorySize而不是推断的值io.netty.maxDirectMemory）而不是eg DIRECT_MEMORY_LIMIT（它将被设置为 的显式或推断值io.netty.maxDirectMemory）？
我可能一路上误解了一些东西，我不一定在抱怨，只是想理解：这是有意的行为吗？疏忽/错误？由于人们现在依赖现有的语义而很难改变的东西？还有别的事吗？