我是否可以尝试使用高级故障排除技术来调试挂起的JavaFX进程？

所以这一次有点像是在抓面条，我想知道是否有人对一些事情有想法，我可能会试图弄清这一点

JRE/JDK是1.8.0_251，运行在Windows 10上。应用程序是使用launch4j启动的JavaFX应用程序

有时，当我退出应用程序时，JVM不会关闭。相反，我在任务管理器中有一个进程，直到我显式地关闭它。它过去是间歇性的，现在几乎是恒定的

我怀疑有一个用户线程被卡住了，它阻止了应用程序关闭。但是，我无法收集有用的线程转储，以查看是否可以识别线程的创建位置

当我遇到这种情况时，我通过tasklist/wmic识别流程ID（JMC没有看到流程），然后尝试对其运行jstack：

• “jstack-F”可以工作，但会删除所有有用的信息，如线程名称或线程类型（守护进程/用户）。所有线程都不包含对我的代码的任何引用
• “jstack-l”曾经起作用，我看到两个受影响的线程名为“pool-#-thread-#”，它们不是守护进程线程，但在JRE更新推送到我的机器后，我不得不安装_251JDK，从那以后，它就永远挂起了。（我让它运行了几个小时，没有变化）

如果我能够重新运行jstack-l，这将大大有助于我识别导致这种情况的执行者池。应用程序生成了几个不同的池，我所知道的几个池都在它们生成的线程上显式地设置了守护进程标志

有趣的是，我在从Eclipse运行应用程序时遇到了类似的问题。我团队中的其他人都无法重现这个问题，而这个问题是在我收到一台替换笔记本电脑后才开始出现的。你可能会认为，如果有一个粘性用户线程，其他人也会看到同样的问题。这让我觉得可能涉及到一些环境/硬件问题，或者我可能触发了一个JRE bug

---

有没有人成功地解决了jstack挂起的问题？在应用程序无法关闭时获取线程转储有什么诀窍吗？

因此，在再次研究这个问题一段时间后，我至少取得了一些进展，并且对问题的原因有了很好的了解，尽管目前还不一定知道如何解决它

通过jstack-F获取的线程转储包含一条我忽略的线索，因为我一直关注的是，在接收到的输出中没有线程名称/守护进程状态：

Thread 22: (state = IN_NATIVE)
- com.sun.prism.d3d.D3DPipeline.nDispose() u/bci=0 (Interpreted frame)
- com.sun.prism.d3d.D3DPipeline.dispose() u/bci=49, line=164 (Interpreted frame)
- com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.cleanup() u/bci=9, line=118 (Interpreted frame)
- com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run() u/bci=14, line=127 (Interpreted frame)
- java.lang.Thread.run() u/bci=11 (Interpreted frame)

多年来一直支持Java，我知道硬件加速的Java UI在某些图形卡/驱动程序方面可能会遇到问题。因此，我尝试在JVM上使用

-Dsun.java2d.d3d=false

标志禁用d3d渲染器。无法复制悬挂

当然，对我来说，仅仅禁用硬件加速并不是理想的解决方案，所以我一直在深入研究解决这个问题。上面的调用堆栈让我了解了

-Dprism.verbose

标志，该标志为我提供了有关正在使用的卡的更多信息。（内部英特尔GPU，而不是我的外部GPU）

此后，我尝试升级驱动程序，并将研究如何将prism从使用intel芯片组切换到专用GPU，看看这是否解决了问题。但至少，我可以选择完全禁用d3d加速