gpt4 book ai didi

Java 外部化与 transient

转载 作者:塔克拉玛干 更新时间:2023-11-01 22:43:26 26 4
gpt4 key购买 nike

我在考虑外部化的目的,因为您可以简单地将属性标记为 transient 并阻止其序列化。但是,经过进一步研究,我发现如果您需要在运行时决定需要什么,这种方法(即标记为 transient)可能并不理想。从理论上讲,这对我来说很有意义。但是,实际上我看不出 Externalization 如何对运行时更友好。我的意思是,您仍然必须在类定义期间决定 writeExternal()readExternal() 中需要什么或不需要什么。那么,如何使运行时更友好?

强调这一点的文件如下,

If everything is automatically taken care by implementing the Serializable interface, why would anyone like to implement the Externalizable interface and bother to define the two methods? Simply to have the complete control on the process. OKay... let's take a sample example to understand this. Suppose we have an object having hundreds of fields (non-transient) and we want only few fields to be stored on the persistent storage and not all. One solution would be to declare all other fields (except those which we want to serialize) as transient and the default Serialization process will automatically take care of that. But, what if those few fields are not fixed at design tiime instead they are conditionally decided at runtime. In such a situation, implementing Externalizable interface will probably be a better solution. Similarly, there may be scenarios where we simply don't want to maintain the state of the Superclasses (which are automatically maintained by the Serializable interface implementation).

最佳答案

我想指出的是,在比较 SerializableExternalizable 方法时,还有其他优点/缺点需要考虑。

外部化更快

在序列化过程中,JVM 总是首先检查类是否可外部化。如果是这种情况,那么它将使用 read/writeExternal 方法。 (有道理,对吧)

可外部化的类需要较少的递归,因为您可以准确地识别您需要的数据。它还会产生更紧凑的输出(更少的字节),这将我们带到下一点......

外部化输出更紧凑

如果你比较实际的输出,它看起来像这样:对象的 header 包含一个标志,用于标记该类是Serializable 还是 Externalizable

OBJECT
CLASSDESC
Class Name: "MyClassName"
Class UID: ...
Class Desc Flags: SERIALIZABLE or EXTERNALIZABLE

如果它只是SERIALIZABLE,那么将跟随一个字段列表(就像一个定义),然后是实际数据。对每个序列化对象重复此操作。

  Field Count: ...
// followed by an bunch of declarations of objects
Field type: object
Field name: "fieldName"
Class name: "Ljava/lang/String;"

// followed by the actual data
STRING: "foo"
STRING: "bar"
float: 123456

可外部化对象不包含字段和数据列表,它们只包含按照您保存的顺序编码的数据。

  EXTERNALIZABLE: [00 AA 00 BC ... ]

外部化更灵活

如果您保存购物 list ,那么您只需要产品名称,对吧?

public class ShoppingList implements Externalizable {
String name;
List<Product> productList;

@Override
public void writeExternal(ObjectOutput pOutput) throws IOException
{
out.writeUTF(name);
for (Product product : productList)
{
// save only product id
out.writeUTF(product.getEanCode());
}
}
...
}

但是,如果您要结帐,那么您也想节省价格吧?

public class Bill implements Externalizable {
String name;
List<Product> productList;

@Override
public void writeExternal(ObjectOutput pOutput) throws IOException
{
out.writeUTF(name);
for (Product product : productList)
{
// save product id and price
out.writeUTF(product.getEanCode());
out.writeInt(product.getPrice());
}
}
...
}

因此,在某些情况下价格是暂时的,而在某些情况下则不是。您将如何使用 transient 关键字解决此问题? -- 我会让你弄清楚这一点。当只使用 transient 关键字时,这种灵 active 确实缺失了。

设计注意事项

但是,也存在一些危险。 只能为具有公共(public)默认构造函数的对象实现外部化对象(一个没有参数的公共(public)构造函数)。

这使得不可能使非静态内部类Externalizable。问题在于 JVM 在运行时修改构造函数,并在编译期间添加对父类的引用。因此,您不能为非静态内部类设置默认的无参数构造函数。

您还必须考虑将来修改您的对象的可能性(例如添加非 transient 字段)。可序列化类可能存在向后兼容性问题,但本身不需要更改代码。可外部化的类将需要在您的读/写方法中更改代码,但有更多选项来处理兼容性问题。

还有一件事。如果您选择这种“技术”在不同的应用程序之间进行通信,那么请不要这样做。你想要的是 JAXB 。它不那么紧凑,但更透明,没有兼容性问题,而且同样灵活。

隐藏功能

为了完整,还有一件事使这个话题变得有点复杂。实际上完全可以在不使用 Externalizable 接口(interface)的情况下使用读/写方法。在引入 Externalizable 之前,可以定义 private writeObjectreadObject 方法。但实际上,您不应该再使用该方法。

关于Java 外部化与 transient ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31131567/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com