我有一种感觉，我会问一个“愚蠢”的问题，但我必须问......
我有2台虚拟机。
我想将一个对象的实例从一个复制到另一个
是否可以在VM的堆中复制代表该对象的位，将其发送到另一个VM，就像另一个VM只需要在其内存中分配位并在其堆栈中添加一个引用到该内存槽...？
目前，为了做这样的事情，我们序列化对象并对其进行反序列化，这比仅仅按原样复制实例效率低（计算方面）......解析是一种计算浪费......
JS序列化示例：每个VM都是V8（JavaScript）的实例，
一种方法是将对象转换为JSON（JSON.stringify），将其发送给另一个获取字符串并将其转换回对象的VM（例如var myObject = eval('(' + myJSONtext + ')');）。（JavaScript这只是一个例子，这是某种序列化）
答案 0 :(得分：7)
让我们暂时忽略一个天真的假设，即你可以轻松地在多个虚拟机上概括这个问题。任何构建此类机制的尝试都将严重依赖于您构建机制的VM的实现细节。
以下是为什么不这样做的几个原因：
内核表示通常不能跨架构移植。如果我在SPARC机器上的VM上发送“对象”到x86机器上的VM而不知道其结构，则该对象在另一侧会显示为损坏。
对象不会存在于两台机器上的同一内存位置，因此对象内的内部指针需要在到达第二个VM后进行修补。这也需要对象结构的内部知识。
对象可能包含对其他对象的引用，因此复制对象意味着复制对象树，通常也不是非循环树。您最终构建的代码看起来非常像序列化库，以便可靠地执行此操作。
对象通常会保留无法通过计算机可靠传输的本机资源（如文件句柄和套接字）。
在许多虚拟机中，数据（您尝试复制的对象）与元数据（例如，您要复制的对象的类）之间存在差异。在这些类型的VM中，即使您可以无损地逐位复制对象，也可能依赖于远程端不存在的一堆元数据。逐位复制元数据也很棘手，因为许多虚拟机使用实现技术（例如内部字符串或内存映射目标代码的全局池）使数据本身不可移植。您最终可能会得到比您想要的更多的元数据（例如，在.net中，您可以打包并发送到某处的最小元数据单元通常是一个程序集）。
内核表示通常不能在同一个VM的不同版本之间移植，也不包含可用于修补数据的内部版本信息。
内核表示包含许多不需要复制的内容（例如内联缓存，垃圾收集信息）。复制这些东西会很浪费，而另一方面的信息甚至可能都不合理。
基本上，为了可靠地执行此操作，您最终会构建世界上最笨拙且不可靠的序列化库，并且在修复因天真复制时会破坏的许多内容时，简单内存副本的性能提升会丢失。
因此，这些机制往往不存在。
此规则有一个很大的例外：基于映像的虚拟机（例如许多smalltalk和自VM）是围绕虚拟机状态存在于可以在机器之间复制，移动的“图像”的想法构建的，这通常会带来很大的性能成本。
答案 1 :(得分：2)
为什么不使用cpickle。它会非常可靠地非常快速地序列化数据，然后你可以通过一个名为pipe，mmap的套接字发送它，你可以命名它，除非在另一端你可以期望可靠地重新组装它，只要它没有在传输中被破坏而泡菜模块的版本并没有太大的不同。当然，真正的企业方法是使用平台无关的标准，例如XML，这将使您可以扩展python之外的平台互操作性。我知道这回避了这个问题，但我认为有人为python解释器代码库做出了贡献，必须为你澄清这一点。
答案 2 :(得分：0)
我确信在VMware API中无法进行这种直接内存传输;我不知道其他的管理程序，但我仍然有点怀疑。 VMware有办法将整个机器的内存运送到另一台主机服务器（主要通过使用分页文件），但没有任何东西只能从正在运行的程序中提取一块内存并将其提供给另一台 - 这涉及太多那里。
所以你现有的对象序列化策略绝对是满足这种需求的一个很好的通用解决方案，幸运的是你正在使用的编程语言有很好的选择（Python，Java）。
但我想知道你是否真的需要将整个对象藏匿并重新创建，或者只是包含了一些数据。如果数据不是过多，您可以使用某种remote method invocation从源VM向接收方发送消息，告知它使用此数据创建对象。在这种情况下，您将仅序列化必要的数据，并让目标机器在其自己的内存中重新构建对象。