这里的问题是，以前给您提供附件的海报
ObjectOutputStream使您误入歧途。一个
ObjectOutputStream/
ObjectInputStream试图存储每个对象只有一次，再后来重提已存储的对象。也就是说，在流中，如果您有一堆相同类的对象，则可以得到如下所示的结果：
CLASS_1_DEscriptIONOBJECT_1REF_TO_CLASS_1OBJECT_2REF_TO_CLASS_1OBJECT_3...
当
ObjectInputStream将流转换回一堆对象时，它将维护已反序列化的内容的列表。它告诉您的错误是它试图对对象进行反序列化，读取了应该是对该对象类的描述的引用，但是当在其内部表中查找该引用时，它看到了一个
String。很自然地，它炸了。
我认为解决方法很简单-在您中
AppendableObjectOutputStream，更改此方法：
@Override protected void writeStreamHeader() throws IOException { // do not write a header, but reset the handle list reset(); }中的
reset()方法在
ObjectOutputStream流中插入一个标记，表示“此时放弃所有状态”。然后，当您使用读回来时
ObjectInputStream，输入流对反序列化的想法将与输出流首先对东西进行反序列化时所认为的状态相匹配。
（编辑：从评论中回答问题）
我能想到的唯一有害后果是：
如果将所有内容全部写入一个文件，则最终文件将比原文件更长
ObjectOutputStream
，尤其是同一Profile
对象出现多次时。即使没有，您也将在流中重复类描述符，因此{openAppendableObjectOutputStream
，编写一个对象，close stream}的许多重复操作可能会使文件大小变大。与此相关的是，在对所有内容进行反序列化之后，您可能最终会获得原本应该是同一对象的多个副本。例如，假设您编写了一堆东西，包括一些
PPRestrictedAccount
对象，然后关闭流，将其作为打开AppendableObjectOutputStream
，并写出一个aPPBusinessAccount
，该operators
列表中包含PPRestrictedAccount
您先前写的一些s。当你阅读所有回的PPRestrictedAccount
就是你读最初不会是相同的对象（也就是说，他们不会==
）的PPRestrictedAccount
是你们等在找到PPBusinessAccount
的operators
名单。它们将分别实例化。为避免这种情况，您需要使用readResolve
方法对它们进行重复数据删除。一切都写到一个AppendableObjectOutputStream
实例将正确连接。根据您的应用程序，这可能根本不用担心。
就遗嘱的安全性而言，这与java序列化的任何其他用法一样安全。没有任何关于您的类的具体信息可以使其正常工作。请注意，在输出文件的多个单独的开口中编写的任何对象都将反序列化为原始对象的单独副本。（没有任何
readResolve魔法）
