gpt4 book ai didi

java - 运行多线程代码时内存不足异常

转载 作者:搜寻专家 更新时间:2023-11-01 03:07:06 26 4
gpt4 key购买 nike

我正在从事一个项目,其中我将拥有不同的 bundle 。让我们举个例子,假设我有 5 个 bundle ,每个 bundle 都有一个方法名称 process

现在,我正在使用下面的多线程代码并行调用所有这 5 个包的 process 方法。

但不知何故,每当我运行下面的多线程代码时,它总是给我内存不足异常。但是,如果我按顺序运行它,即一个一个地调用进程方法,那么它不会给我任何内存不足异常。

下面是代码-

public void callBundles(final Map<String, Object> eventData) {

// Three threads: one thread for the database writer, two threads for the plugin processors
final ExecutorService executor = Executors.newFixedThreadPool(3);

final Map<String, String> outputs = (Map<String, String>)eventData.get(Constants.EVENT_HOLDER);

for (final BundleRegistration.BundlesHolderEntry entry : BundleRegistration.getInstance()) {
executor.submit(new Runnable () {
public void run() {
try {
final Map<String, String> response = entry.getPlugin().process(outputs);

//process the response and update database.
System.out.println(response);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
}

下面是异常,每当我在多线程代码之上运行时我都会得到。

JVMDUMP006I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError" - please wait.
JVMDUMP032I JVM requested Heap dump using 'S:\GitViews\Stream\goldseye\heapdump.20130904.175256.12608.0001.phd' in response to an event
JVMDUMP010I Heap dump written to S:\GitViews\Stream\goldseye\heapdump.20130904.175256.12608.0001.phd
JVMDUMP032I JVM requested Java dump using 'S:\GitViews\Stream\goldseye\javacore.20130904.175256.12608.0002.txt' in response to an event
UTE430: can't allocate buffer
UTE437: Unable to load formatStrings for j9mm
JVMDUMP010I Java dump written to S:\GitViews\Stream\goldseye\javacore.20130904.175256.12608.0002.txt
JVMDUMP032I JVM requested Snap dump using 'S:\GitViews\Stream\goldseye\Snap.20130904.175256.12608.0003.trc' in response to an event
UTE001: Error starting trace thread for "Snap Dump Thread": -1
JVMDUMP010I Snap dump written to S:\GitViews\Stream\goldseye\Snap.20130904.175256.12608.0003.trc
JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError".
ERROR: Bundle BullseyeModellingFramework [1] EventDispatcher: Error during dispatch. (java.lang.OutOfMemoryError: Failed to create a thread: retVal -1073741830, errno 12)
java.lang.OutOfMemoryError: Failed to create a thread: retVal -1073741830, errno 12

JVMDUMP006I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError" - please wait.
JVMDUMP032I JVM requested Heap dump using 'S:\GitViews\Stream\goldseye\heapdump.20130904.175302.12608.0004.phd' in response to an event
JVMDUMP010I Heap dump written to S:\GitViews\Stream\goldseye\heapdump.20130904.175302.12608.0004.phd
JVMDUMP032I JVM requested Java dump using 'S:\GitViews\Stream\goldseye\javacore.20130904.175302.12608.0005.txt' in response to an event

我正在使用 JDK1.6.0_26 作为在我的 eclipse 中安装的 JRE。

最佳答案

每次调用 callBundles() 都会通过创建一个自己的执行器来创建一个新的线程池。每个线程都有自己的堆栈空间!因此,如果您说启动 JVM,第一次调用将创建三个线程,堆总和为 3M(1024k 是 64 位 JVM 的默认堆栈大小),下一次调用另一个 3M 等。1000 次调用/秒将需要3GB/秒!

第二个问题是您永远不会shutdown() 创建的执行程序服务,因此线程将继续运行,直到垃圾收集器删除执行程序(finalize() 也调用关闭())。但是 GC 永远不会清除堆栈内存,因此如果堆栈内存有问题并且堆未满,GC 将无济于事!

您需要使用一个 ExecutorService,假设有 10 到 30 个线程,或者一个自定义的 ThreadPoolExecutor 有 3-30 个缓存线程和一个LinkedBlockingQueue。如果可能,在您的应用程序停止之前调用服务上的 shutdown()

检查应用程序的物理 RAM、负载和响应时间,以调整参数堆大小、最大线程数和池中线程的存活时间。查看代码的其他锁定部分(数据库连接池的大小,...)和服务器的 CPU/内核数。线程池大小的起始点可能是 CPU 数/内核加 1。I/O 等待越多越有用。

关于java - 运行多线程代码时内存不足异常,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18626142/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com