不久前有一个JSR 323 proposed for this，但它是rejected。你可以在那些文章中找到一些关于这个背后的研究和它需要什么的链接。它大多被拒绝，因为这个想法太不成熟了。
我听说过至少一家创业公司（很遗憾，我记不起名字了），该公司致力于虚拟机管理程序上的虚拟化技术（可能是Xen），它已经非常接近能够移动JVM，甚至包括文件系统引用和套接字端点。因为它们处于hypervisor级别，所以它们可以访问所有这些东西。通过将其与JVM挂钩，他们有大部分的碎片。我想他们可能已经沉了。
目前最接近的是Terracotta，它允许您对JVM堆的一部分进行集群，将其存储在一个服务器阵列中，该阵列可以持久化。在JVM启动时，您连接到集群，并可以继续使用指定为集群的堆的任何部分。实际对象根据需要进行故障处理。

目前还不可能。一般来说，在不同的上下文中暂停和重新启动进程的内存映像是非常难以实现的：你打算用开放操作系统资源做什么？2传输到具有不同指令集的机器上？3数据库连接？
而且，运行JVM的映像可能非常大--可能比您实际感兴趣的状态子集大得多。因此，从性能Angular 来看，这不是一个好主意。
一个更好的策略是让代码持久化并重新创建应用程序状态：这对于大多数JVM动态语言来说是相对可行的，我在Clojure中做了类似的事情，在Clojure中你有一个交互式环境（REPL），并且很可能创建和运行一系列操作来重建你想要在另一个JVM中的应用程序状态。

这在我所知道的任何JVM中都是不可能的。如果程序与其环境断开连接运行，在JVM中实现这样的东西并不难。然而，许多程序都有与其环境的挂钩（想想文件句柄、数据库连接），这将使实现这样的东西非常困难。

截至2023年初，这一领域取得了一些进展，似乎有很多东西至少可以尝试，即使没有声称他们的生产准备。
其中一个特性叫做CRaC，你可以检查他们的docs，甚至可以得到一个包含这个特性的OpenJDK build，这个项目在OpenJDK下有它的own repo，看起来很有前途。
要检查的其他供应商/产品：Azul ReadyNow!OpenJ9 InstantOn
同样令人兴奋的是AWS Lambda SnapStart，它没有给予完整的快照功能，本质上是特定于供应商的，但它是大量使用AWS Lambda的Java工程师等待已久的东西。