JVM应该退出但没有

Question

在非gui模式下使用Jmeter 3.3进行分布式测试的过程中，我得到的错误是，如何修复此问题：

我在主机器和从机器上使用相同版本的JMeter和JDK。

JVM应该已经退出，但没有退出。以下非守护进程线程仍在运行（DestroyJavaVM正常）：线程[main，5，main]，

stackTrace:java.net.SocketInputStream#socketRead0
java.net.SocketInputStream#socketRead
java.net.SocketInputStream#read
java.net.SocketInputStream#read
java.io.BufferedInputStream#fill
java.io.BufferedInputStream#read
java.io.DataInputStream#readByte
sun.rmi.transport.StreamRemoteCall#executeCall
sun.rmi.server.UnicastRef#invoke
java.rmi.server.RemoteObjectInvocationHandler#invokeRemoteMethod
java.rmi.server.RemoteObjectInvocationHandler#invoke
com.sun.proxy.$Proxy19#rrunTest
org.apache.jmeter.engine.ClientJMeterEngine#runTest at line:149
org.apache.jmeter.engine.DistributedRunner#start at line:132
org.apache.jmeter.engine.DistributedRunner#start at line:149
org.apache.jmeter.JMeter#runNonGui at line:1005
org.apache.jmeter.JMeter#startNonGui at line:910
org.apache.jmeter.JMeter#start at line:538
sun.reflect.NativeMethodAccessorImpl#invoke0
sun.reflect.NativeMethodAccessorImpl#invoke
sun.reflect.DelegatingMethodAccessorImpl#invoke
java.lang.reflect.Method#invoke
org.apache.jmeter.NewDriver#main at line:248

Answer 1

最可能的情况是，您的JMeter引擎过载，因此当您请求运行的线程关闭时，无法正常关闭它们。

>

确保您遵循JMeter最佳实践

第一个最佳实践状态总是使用JMeter的最新版本，所以考虑迁移到JMeter 5.0或JMeter下载页面上提供的任何最新版本

确保您的JMeter实例有足够的余量来操作CPU、RAM等。如果您没有其他监控软件，您可以使用JMeter PERMon插件。

取一个线程转储并检查它-这样你就会知道你的测试到底卡在哪里

在HTTP请求默认值中引入合理的超时值，以便在服务器无法响应的情况下，JMeter不会无限等待，而是以错误失败

最后（但是我不建议这样做），您可以通过在文件中添加下一行来取消user.properties检查：

jmeter.exit.check.pause=-1

如果你这样做，请记住，你可能会遇到这样一种情况，即使在测试结束后，JMeter从服务器仍然会试图执行一些东西，所以你需要手动或使用脚本杀死并重启进程。

Answer 2

我强烈建议使用此jmeter属性：

jmeterengine.force.system.exit=true

记录在这里。这些中文网页给我通风报信。

您可以在启动JMeter时在命令行上添加-Jjmeterengine.force.system.exit=true，或将jmeterengine.force.system.exit=true添加到JMETER_HOME/bin/jmeter.properties.

我是如何确认这个修复的

对于MS-Win10上的JMeter 5.1和java版本“1.8.0ç”，我们正在使用此JMeter XDB后端侦听器的自定义版本。在我从命令行（jmeter.bat-n-tplan.jtl）进行了60秒的测试运行后，命令行在显示此输出后挂起（非常类似于op）：

Tidying up ...    @ Wed Jan 29 14:41:04 CST 2020 (1580330464874)
... end of run
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[DestroyJavaVM,5,main], stackTrace:
Thread[pool-2-thread-3,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#parkNanos
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#awaitNanos
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ThreadPoolExecutor#getTask
java.util.concurrent.ThreadPoolExecutor#runWorker
java.util.concurrent.ThreadPoolExecutor$Worker#run
java.lang.Thread#run

Thread[pool-2-thread-4,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#parkNanos
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#awaitNanos
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ThreadPoolExecutor#getTask
java.util.concurrent.ThreadPoolExecutor#runWorker
java.util.concurrent.ThreadPoolExecutor$Worker#run
java.lang.Thread#run

Thread[pool-2-thread-1,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#parkNanos
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#awaitNanos
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ThreadPoolExecutor#getTask
java.util.concurrent.ThreadPoolExecutor#runWorker
java.util.concurrent.ThreadPoolExecutor$Worker#run
java.lang.Thread#run

在如下修改我的命令行后，jmeter.bat干净利落地退出而不是挂起，所有丑陋的堆栈跟踪也消失了：

jmeter.bat -n -Jjmeterengine.force.system.exit=true -t plan.jtl 

为了确认该问题是由我们自定义的JMeter ImverxDB后端监听器引起的，我从. jmx中删除了它，还删除了jmeterengine.force.system.exit=true。没有挂，没有丑陋的堆栈痕迹（我实际上喜欢堆栈痕迹）。

我还没有采取下一步来发现问题是出在正式的JMeter xdb后端监听器上，还是出在我们定制的变体上，后者现在（将来也永远）不公开。

应该提到这个故事中的一个缺口。我觉得这个测试最终指向了我们定制的后端监听器（或jmeter）。然而，奇怪的是，上面的线程转储中似乎没有一个线程属于后端侦听器。因此，我称赞JMeter通过转储堆栈跟踪做了正确的事情——很少有其他应用在适当的故障排除时达到自动转储的程度。但在本例中，可能需要增强jmeter自动转储代码，因为它没有指向罪魁祸首后端侦听器代码。阿帕奇那边有人在听吗？

祝你好运。