Блог

Я просматривал эту статью, чтобы больше понять процесс сериализации Java. Когда дело доходит до использования readObject/writeObject , я мог видеть два варианта использования:

1. Мы можем использовать writeObject для шифрования байтового кода перед его сериализацией. С точки зрения безопасности, это хорошая вещь.
2. мы можем использовать readObject для выполнения любого конкретного фрагмента кода, который необходимо выполнить сразу после десериализации, и, отклоняясь от пункта 1, мы можем даже использовать readObject для расшифровки байтового кода, который был удален при сериализации объекта.

Есть ли какой-либо другой практический сценарий, с которым вы столкнулись при сериализации / десериализации объектов путем написания пользовательского метода readObject / writeObject? Или, если бы вы могли указать мне на любое место, где я мог бы увидеть некоторые достойные и практические применения readObject / writeObject?

Пользовательские readObject методы также полезны, когда вам нужно инициализировать временные (несериализованные) поля после десериализации объекта.

Кстати, ознакомьтесь с Эффективной Java, глава 11 (я не уверен, какой номер главы / элемента во 2-м издании.). Это отличное чтение о сериализации.

Вы можете реализовать свой собственный readObject / writeObject по соображениям производительности или обратной совместимости, или потому, что поле, которое вы хотите сериализовать, не является сериализуемым.

Хорошие примеры readObject / writeObject я бы поискал в исходном коде, который поставляется вместе с JDK. Или я бы попробовал http://www.google.co.uk/search ?q=readObject writeObject примеры

Может быть несколько причин для использования пользовательской сериализации:

1. Производительность.
2. Взаимодействие с внешними системами. (Недоступные для вас или даже просто не Java-системы.)
3. Требуется формат, понятный человеку.
4. Поддержка более старых версий сериализованных классов.

Назову лишь некоторые, но я уверен, что их гораздо больше.

 public class Employee implements Serializable {

    private static final long serialVersionUID = 1L;

    private int empno;
    private String ename;
    private String job;

    // setter amp; getter

    @Override
    public String toString() {
        return "Employee [empno="   empno   ", ename="   ename   ", job="   job
                  "]";
    }

    private void writeObject(ObjectOutputStream out) throws IOException {

        // default serialization
        // out.defaultWriteObject();

        // custom serialization
        out.writeInt(empno);
        out.writeUTF(ename);
        // out.writeUTF(job); //job will not serialize
    }

    private void readObject(ObjectInputStream in) throws IOException,
            ClassNotFoundException {

        // default deSerialization
        // in.defaultReadObject();

        // custom deSerialization
        empno = in.readInt();
        ename = in.readUTF();
        // this.job = in.readUTF();
    }

}
  

Я думаю, что дешифрование может быть лучше выполнено с использованием ObjectOutputStream на основе CipherOutputsStream.

Наиболее важное использование writeObject / readObject — это если вы хотите сохранить стабильность сериализации при нескольких версиях кода. Ваше внутреннее представление (переменные-члены) может измениться, но сериализация должна быть стабильной, поскольку вы взаимодействуете со старой системой (например, путем чтения старых данных из файлов).

Но я предпочитаю экстернализуемый интерфейс для этих случаев, поскольку он проще в использовании (никаких неявных вызовов и методов, о которых знает только jvm).

Методы writeObject() и readObject() также используются для предотвращения сериализации объекта.

Когда суперкласс реализует Serializable, все его подклассы сериализуемы по умолчанию. Но если вы хотите, чтобы подкласс не был сериализуемым, переопределите методы writeObject() и readObject() в подклассе, как показано ниже

 class Parent implements Serailizable
{
    int id;

} 

class child extends Parent
{
   String name;

   private void writeObject(ObjectOutputStream out) throws NotSerializableException
    {
        throw new NotSerializableException();
    }
    
    private void readObject(ObjectInputStream in) throws NotSerializableException
    {
        throw new NotSerializableException();
    }

}
  

Теперь объекты подкласса не могут быть сериализованы.

Одним из интересных вариантов использования для readObject является реализация сериализуемого синглтона, где мы хотим, чтобы экземпляр Singleton сохранял значения полей, которые были определены до сериализации. Итак, во время десериализации экземпляра Singleton мы хотим, чтобы значения полей были точно такими же, как до сериализации, даже если они могли быть изменены перед сериализацией и десериализацией.

 @Serial
private void readObject(ObjectInputStream objectInputStream) throws IOException, ClassNotFoundException {
    boolean deserializedField = objectInputStream.readFields().get("field", isField());
    instance.setField(deserializedField);
}

@Serial
public Object readResolve() {
    return instance;
}
  

Кроме того, здесь нам нужен другой полезный метод readResolve , чтобы всегда возвращать ссылку на одноэлементный экземпляр вместо десериализованного объекта.