Java 应用程序通过 JNI 调用 C++ DLL；如何最好地分配内存？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7700446/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java app calls C++ DLL via JNI; how best to allocate memory?
提问by JoshDM
Basic summary of question is: How do I best optimize my memory allocation to give as much memory to the DLLs I access through JNI as possible? What should I aim to minimize, what should I aim to maximize, etc.
问题的基本摘要是：如何最好地优化我的内存分配，以便为我通过 JNI 访问的 DLL 提供尽可能多的内存？我应该最小化什么，我应该最大化什么，等等。
SYSTEM: Running JBoss 6 as a Windows 32 Service in a 32-bit system with 4 GB RAM. I do understand there are maximum restrictions on memory for Java Heap. JVM is JRE1.6.0_26
系统：在具有 4 GB RAM 的 32 位系统中将 JBoss 6 作为 Windows 32 服务运行。我知道 Java 堆的内存有最大限制。JVM 是JRE1.6.0_26
SERVICE: Installed under JBoss is a webapp which receives requests from clients; each request calls the C++-built DLL through JNI to process an image file in some fashion or other.
SERVICE：安装在 JBoss 下的是一个 webapp，它接收来自客户端的请求；每个请求都通过 JNI 调用 C++ 构建的 DLL 以某种方式或其他方式处理图像文件。
ISSUE: Occasionally, with larger or some (not all) LZW-compression images, the calling java class receives a message that the DLL experienced a Global Memory Depletion and failed to complete the requested process.
问题：有时，对于较大的或部分（不是全部）LZW 压缩图像，调用 java 类会收到一条消息，指出 DLL 遇到全局内存耗尽并且无法完成请求的进程。
There is nothing else actively running on the server beyond basic windows processes.
除了基本的 Windows 进程之外，服务器上没有其他正在运行的东西。
Current JBOSS App Server memory settings are as follows, but may be excessive:
当前 JBOSS App Server 内存设置如下，但可能过多：
-Xms1024m -Xmx1024m -Xss1024k -XX:MaxPermSize=128m
-Xms1024m -Xmx1024m -Xss1024k -XX:MaxPermSize=128m
I am trying to determine the best memory settings to give as much resources to the JNI DLL, as I understand JNI does not use any memory allocated to the Java Heap.
我正在尝试确定最佳内存设置，以便为 JNI DLL 提供尽可能多的资源，因为我了解 JNI 不使用分配给 Java 堆的任何内存。
I have read these, but did not find them helpful to answer my question:
我已经阅读了这些，但没有发现它们对回答我的问题有帮助：
Java JNI : Memory allocation / partitioning
Can jconsole be used to identify memory leaks in JNI C++ objects?
jconsole 可以用于识别 JNI C++ 对象中的内存泄漏吗？
The two answers currently supplied do not address the inherient question.
当前提供的两个答案并未解决固有问题。
Current memory of JBoss server after one week with JVM params set as above (TaskManager indicates java.exe process at 750,672k)
JVM 参数如上设置一周后 JBoss 服务器的当前内存（TaskManager 指示 java.exe 进程为 750,672k）
Total Memory Pools: 5
Pool: Code Cache (Non-heap memory)
Peak Usage : init:2359296, used:7317312, committed:7438336, max:50331648
Current Usage : init:2359296, used:7306496, committed:7438336, max:50331648
|---------| committed:7.09Mb
+---------------------------------------------------------------------+
|/////////| | max:48Mb
+---------------------------------------------------------------------+
|---------| used:6.97Mb
Pool: PS Eden Space (Heap memory)
Peak Usage : init:268500992, used:354811904, committed:354811904, max:355991552
Current Usage : init:268500992, used:270153472, committed:354091008, max:354156544
|--------------------------------------------------------------------| committed:337.69Mb
+---------------------------------------------------------------------+
|///////////////////////////////////////////////////// || max:337.75Mb
+---------------------------------------------------------------------+
|----------------------------------------------------| used:257.64Mb
Pool: PS Survivor Space (Heap memory)
Peak Usage : init:44695552, used:44694896, committed:78643200, max:78643200
Current Usage : init:44695552, used:0, committed:1835008, max:1835008
|---------------------------------------------------------------------| committed:1.75Mb
+---------------------------------------------------------------------+
| | max:1.75Mb
+---------------------------------------------------------------------+
| used:0b
Pool: PS Old Gen (Heap memory)
Peak Usage : init:715849728, used:123671968, committed:715849728, max:715849728
Current Usage : init:715849728, used:104048648, committed:715849728, max:715849728
|---------------------------------------------------------------------| committed:682.69Mb
+---------------------------------------------------------------------+
|////////// | max:682.69Mb
+---------------------------------------------------------------------+
|---------| used:99.23Mb
Pool: PS Perm Gen (Non-heap memory)
Peak Usage : init:16777216, used:91989664, committed:134217728, max:134217728
Current Usage : init:16777216, used:90956472, committed:90963968, max:134217728
|----------------------------------------------| committed:86.75Mb
+---------------------------------------------------------------------+
|//////////////////////////////////////////////| | max:128Mb
+---------------------------------------------------------------------+
|----------------------------------------------| used:86.74Mb
回答by allingeek
Memory allocated by the native code wrapped by JNI is allocated to the JVM process, but is not under the control of your Java code. It is not part of the heap, and is not tunable via JVM parameters. Basically, anything allocated with a native malloc must be managed by that native code. If you are in control of the libraries you are using, its imperative that you go through it and check for resource leaks. This is especially important if this is being used in a long lived process.
由 JNI 包装的本机代码分配的内存分配给 JVM 进程，但不受您的 Java 代码的控制。它不是堆的一部分，也不能通过 JVM 参数进行调整。基本上，使用本机 malloc 分配的任何内容都必须由本机代码管理。如果您可以控制正在使用的库，则必须通过它并检查资源泄漏。如果这是在长期过程中使用，这一点尤其重要。
In my experience the best approach would be to examine your actual memory use by pulling the JMX stats exposed by the JVM. Once you have an idea about how much memory your Java app consumes You'll have a better idea about where to set your max heap settings. Permgen space is used for class definitions and such, so you really shouldn't need much memory there unless you are doing a bunch of dynamic class loading.
根据我的经验，最好的方法是通过提取 JVM 公开的 JMX 统计信息来检查您的实际内存使用情况。一旦您了解了 Java 应用程序消耗了多少内存，您就会更好地了解在何处设置最大堆设置。Permgen 空间用于类定义等，所以你真的不应该需要太多内存，除非你正在做一堆动态类加载。
While you cannot tune the memory available for the JNI library, tuning the memory reserved for your heap and such will potentially free up resources for use by the library.
虽然您无法调整 JNI 库的可用内存，但调整为堆保留的内存等可能会释放资源供库使用。
As would be expected, adding the heap memory peaks together it comes out to about 1022.19 (the max size of your heap). When the heap is exhausted a full GC run is kicked off and dirty heap is reclaimed. Based on the numbers that you have provided, I'd suggest starting with a Xmx512m. This will give your JNI code room to breath.
正如预期的那样，将堆内存峰值加在一起，结果约为 1022.19（堆的最大大小）。当堆耗尽时，将启动完整的 GC 运行并回收脏堆。根据您提供的数字，我建议从 Xmx512m 开始。这将为您的 JNI 代码提供喘息的空间。
If you find that the JVM is thrashing due to excessive garbage collection, meaning that you're running out of Java heap too quickly, you could grow that allocation. However, if it is eating up 512mb rapidly enough to cause a noticeable performance impact, its unlikely that anything short of a significant increase will have much effect. This all depends heavily on your program, how quickly it eats the Java heap, and how effective the full GC run is.
如果您发现 JVM 由于过多的垃圾收集而出现抖动，这意味着您过快地用完 Java 堆，您可以增加该分配。但是，如果它以足够快的速度消耗 512 mb 以导致明显的性能影响，那么除了显着增加之外的任何事情都不太可能产生太大影响。这一切都在很大程度上取决于您的程序、它占用 Java 堆的速度以及完整 GC 运行的效率。
