为什么java.util.Optional不可序列化，如何使用此类字段序列化对象

Enum类是可序列化的，因此使用枚举序列化对象没有问题。另一种情况是class具有java.util.Optional类的字段。在这种情况下，将引发以下异常：java.io.NotSerializableException：java.util.Optional

如何处理此类，如何序列化它们？是否可以将此类对象发送到远程EJB或通过RMI？

这是示例：

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.Optional;

import org.junit.Test;

public class SerializationTest {

    static class My implements Serializable {

        private static final long serialVersionUID = 1L;
        Optional<Integer> value = Optional.empty();

        public void setValue(Integer i) {
            this.i = Optional.of(i);
        }

        public Optional<Integer> getValue() {
            return value;
        }
    }

    //java.io.NotSerializableException is thrown

    @Test
    public void serialize() {
        My my = new My();
        byte[] bytes = toBytes(my);
    }

    public static <T extends Serializable> byte[] toBytes(T reportInfo) {
        try (ByteArrayOutputStream bstream = new ByteArrayOutputStream()) {
            try (ObjectOutputStream ostream = new ObjectOutputStream(bstream)) {
                ostream.writeObject(reportInfo);
            }
            return bstream.toByteArray();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

此答案是对标题“是否应该可序列化的可选内容”的问题的答复。简短的答案是Java Lambda（JSR-335）专家组考虑并拒绝了它。这一点，和这一个和这一个表示为主要设计目标Optional是用来作为当了一回值可能是不存在的函数的返回值。目的是调用方立即检查Optional并提取实际值（如果存在）。如果不存在该值，则调用者可以替换默认值，引发异常或应用某些其他策略。通常，通过将流式方法调用链接到返回Optional值的流管道（或其他方法）的末端来完成此操作。

绝不打算Optional将其用于其他方式，例如用于可选方法参数或作为字段存储在object中。通过扩展，可Optional序列化将使其能够持久存储或通过网络传输，这两者都鼓励使用远远超出其原始设计目标。

通常，组织数据要比Optional在字段中存储更好。如果getter（例如问题中的getValue方法）Optional从字段返回实际值，则它将强制每个调用者实施一些用于处理空值的策略。这可能会导致呼叫者之间行为不一致。通常最好让该字段设置的任何代码集在应用时都应用一些策略。

有时人们想放入Optional收藏，例如List<Optional<X>>或Map<Key,Optional<Value>>。这通常也是一个坏主意。通常最好Optional用Null-Object值（不是实际的null引用）代替这些用法，或者只是完全从集合中忽略这些条目。

Serialization通过将持久性序列化形式与您在其上运行的实际运行时实现分离，可以解决许多相关问题。

/** The class you work with in your runtime */
public class My implements Serializable {
    private static final long serialVersionUID = 1L;

    Optional<Integer> value = Optional.empty();

    public void setValue(Integer i) {
        this.value = Optional.ofNullable(i);
    }

    public Optional<Integer> getValue() {
        return value;
    }
    private Object writeReplace() throws ObjectStreamException
    {
        return new MySerialized(this);
    }
}
/** The persistent representation which exists in bytestreams only */
final class MySerialized implements Serializable {
    private final Integer value;

    MySerialized(My my) {
        value=my.getValue().orElse(null);
    }
    private Object readResolve() throws ObjectStreamException {
        My my=new My();
        my.setValue(value);
        return my;
    }
}

该类Optional实现的行为允许在处理可能不存在的值（与的使用相比null）时编写良好的代码。但这并不能给您的数据持久表示带来任何好处。这只会使您的序列化数据更大……

上面的草图可能看起来很复杂，但这是因为它仅演示具有一个属性的模式。您的类具有的属性越多，其简单性就应得到更多的体现。

别忘了，My完全无需更改持久性形式即可完全更改实施的可能性……

如果您想要可序列化的可选内容，请考虑使用可序列化的guava可选内容。

这是一个奇怪的遗漏。

您将不得不将该字段标记为，transient并提供您自己的自定义writeObject()方法来编写get()结果本身，以及一种通过从流中读取结果来readObject()还原方法的方法Optional。不要忘记分别致电defaultWriteObject()和defaultReadObject()。

Vavr.io库（以前的Javaslang）也具有Option可序列化的类：

public interface Option<T> extends Value<T>, Serializable { ... }

如果要维护更一致的类型列表并避免使用null，则有一个怪异的选择。

您可以使用交集类型存储值。加上lambda，可以实现以下功能：

private final Supplier<Optional<Integer>> suppValue;
....
List<Integer> temp = value
        .map(v -> v.map(Arrays::asList).orElseGet(ArrayList::new))
        .orElse(null);
this.suppValue = (Supplier<Optional<Integer>> & Serializable)() -> temp==null ? Optional.empty() : temp.stream().findFirst();

将temp变量分开可以避免关闭value成员的所有者，从而避免序列化过多。