아이템 87. 커스텀 직렬화 형태를 고려해보라

[chikeem90]

• 기본 직렬화 형태를 적용하는 것은 신중하게 결정할 것
• 기본 직렬화 형태란 클래스가 Serializable을 구현하는 형태

public class CartProduct implements Serializable {

• 객체의 물리적 표현과 논리적 내용이 같으면 기본 직렬화 형태도 무방
• 기본 직렬화 형태를 적용한다고 하더라도 불변식 보장과 보안을 위해 readObject 메서드를 제공해야할 때가 있음
  • 특정 필드가 nullable 하지 않은 경우, readObject에서 처리해주어야 함.

• 객체의 물리적 표현과 논리적 표현의 차이가 클 때 기본 직렬화 형태를 사용하면 발생할 수 있는 문제점

public class StringList implements Serializable {
    private int size   = 0;
    private Entry head = null;

    private static class Entry {
        String data;
        Entry  next;
        Entry  previous;
    }

    //
}

• 공개 API가 현재 내부 표현 방식에 영구히 묶임

  • 필드가 새로 추가되거나, 타입이 변경되거나 하면 역직렬화하는 쪽에서도 다 알고 있어야 함.
  • 위 예시에서 StringList는 논리적으로는 단순히 String의 List이지만 내부 구현은 양방향 링크트리스트로 구현되어 있음.
  • 기본 직렬화 형태를 적용함으로써 Entry도 직렬화 대상이 되고 역직렬화 할 때도 내부 구현에 대해 다 알고 있어야하며, 구현을 변경하게 되면 역직렬화하는 쪽에서도 모두 바꿔줘야하기 때문에 변경하기가 어려움.

• 너무 많은 공간을 차지할 수 있음.

  • StringList의 경우 직렬화 대상이 단순히 String의 List가 되면 되지만, Entry가 가지고 있는 값들도 모두 직렬화 되어야하므로 불필요하게 size가 커짐.

• 시간이 너무 많이 걸릴 수 있음.

  • 직렬화 로직은 객체 그래프의 위상에 관한 정보가 없어 그래프를 모두 순회해볼 수 밖에 없음.
  • 위 예시와 같이 복잡한 형태의 경우 순회하는 시간이 오래걸리고 결국 직렬화 역직렬화하는데 오랜 시간이 걸릴 수 있음.

• 스택 오버플로를 일으킬 수 있음.

  • 기본 직렬화 과정은 객체 그래프를 재귀 순회하는데, 중간 정도의 크기의 객체 그래프에서도 스택 오버플로를 일으킬 가능성이 있음.

public class StringList implements Serializable {
    private transient int size   = 0;
    private transient Entry head = null;

    private static class Entry {
        String data;
        Entry  next;
        Entry  previous;
    }

    private void writeObject(ObjectOutputStream s)
        throws IOException {
        s.defaultWriteObject();
        s.writeInt(size);

        for (Entry e = head; e != null; e = e.next)
            s.writeObject(e.data);
    }

    private void readObject(ObjectInputStream s)
        throws IOException, ClassNotFoundException {
        s.defaultReadObject();
        int numElements = s.readInt();

        for (int i = 0; i < numElements; i++)
            add((String) s.readObject());
    }

    public void add(String s) {  }

    //
}

• 기본 직렬화 형태에서 커스텀하여 writeObject와 readObject를 구현.
• 직렬화할 필요 없는 필드들은 transient 한정자 지정.
• 상호 호환을 위해 defaultWriteObject, defaultReadObject를 호출해야 함.

• 기본 직렬화 사용 여부와 상관없이 객체의 전체 상태를 읽는 메서드에 적용해야 하는 동기화 메커니즘을 직렬화에도 적용해야 함.
• 모든 메서드를 synchronized로 선언하여 스레드 안전하게 만든 객체에서 기본 직렬화를 사용하려면 writeObject도 synchronized로 선언해야 함.

• 어느 직렬화 형태를 택하든 직렬화 가능 클래스 모두에 직렬 버전 UID를 명시적으로 부여해야 함.
• 직렬 버전 UID가 일으키는 잠재적인 호환성 문제를 피할 수 있음.
• 런타임에 생성하는 연산을 skip할 수 있어서 성능 측면에서 약간 도움이 됨.
• 새로 작성하는 경우 어떤 long 값을 선택하든 상관 없으며, 반드시 고유한 값일 필요도 없음.
• 직렬 버전 UID가 없는 기존 클래스를 구버전으로 직렬화된 인스턴스와 호환성을 유지한 채 수정하고 싶다면, 구버전에서 사용한 자동 생성된 값을 그대로 사용해야 함.

• 기존 버전 클래스와의 호환성을 끊고 싶다면 단순히 직렬 버전 UID의 값을 바꿔주면 되며, 기존 버전의 직렬화된 인스턴스를 역직렬화할 때 InvalidClassException이 발생하게 될 것.
• 구버전으로 직렬화된 인스턴스들과의 호환성을 끊으려는 경우를 제외하고는 직렬 버전 UID를 절대 수정하지 말 것.