item 87 SeungminLee - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

개발 일정에 쫓기는 상황이라 이번 릴리스에서는 그냥 동작만 하도록 만들어 놓고 다음 릴리즈에서 제대로 구현을 하는게 종종 일어나지만 클래스가 Serializable을 구현하고 기본 직렬화 형태를 사용한다면 다음 릴리스 때 버리려 한 현재의 구현에 영원히 발이 묶이게 된다.

• 기본 직렬화 형태는 유연성, 성능, 정확성 측면에서 신중히 고민한 후 합당할 때만 사용해야 한다.
• 기본 직렬화 형태는 객체가 포함한 데이터들과 그 객체에서부터 시작해 접근할 수 있는 모든 객체를 담아내먀, 심지어 이 객체들이 연결된 위상까지 기술한다.
• 반면 이상적인 직렬화 형태는 물리적인 모습과 독립된 논리적인 모습만을 표현해야 한다.

public class Name implements Serializable {
    
    /**
     * 성. null이 아니어야함
     * @serial
     */
    private final String lastName;
    
    /**
     * 이름. null이 아니어야 함.
     * @serial
     */
    private final String firstName;
    
    /**
     * 중간이름. 중간이름이 없다면 null.
     * @serial
     */
    private final String middleName;
}

• 성명은 논리적으로 이름, 성, 중간이름이라는 3개의 문자열로 구성되며, 앞 코드의 인스턴스 필드들은 이 논리적 구성요소를 정확하게 반영하기 때문에 기본 직렬화를 사용해도 무방하다.
• 세 필드 모두 private임에도 문서화 주석이 달려있다. 이 필드들은 결국 클래스의 직렬화 형태에 포함되는 공개 API에 속하기 떄문이다.

앞의 Name 클래스의 경우에는 readObject 메서드가 lastName과 firstName 필드가 null이 아님을 보장해야 한다.

public final class StringList implements Serializable {
    private int size = 0;
    private Entry head = null;
    
    private static class Entry implements Serializable {
        String data;
        Entry next;
        Entry previous;
    }
}

이 클래스는 직렬화 형태에 적합하지 않다.

논리적으로 이 클래스는 일련의 문자열을 표현한다. 물리적으로는 문자열들을 이중 연결 리스트로 연결했기 때문이다.

이 클래스에 기본 직렬화 형태를 사용하면 각 노드의 양방향 연결 정보를 포함해 모든 Entry 를 철두철미하게 기록한다.

1. 공개 API가 현재의 내부 표현 방식에 영구히 묶인다.
2. 너무 많은 공간을 차지할 수 있다.
3. 시간이 너무 많이 걸릴 수 있다.

직렬화 로직은 객체 그래프의위상에 관한 정보가 없으니 그래프를 직접 순회해 볼 수 밖에 없다.

4. 스택 오버플로를 일으킬 수 있다.

public final class StringList implements Serializable {
    private transient int size = 0;
    private transient Entry head = null;
    
    // 이제는 직렬화되지 않는다.
    private static class Entry {
        String data;
        Entry next;
        Entry previous;
    }
    
    // 지정한 문자열을 이 리스트에 추가한다.
    public final void add(String s) {...}
    
    /**
     * 이 {@code StringList} 인스턴스를 직렬화한다.
     * 
     * @serialData 이 리스트의 크기(포함된 문자열의 개수)를 기록한 후
     * ({@code int}), 이어서 모든 원소를(각각은 {@code String})
     * 순서대로 기록한다.
     */
    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());
        }
    }
}

transient: 해당 인스턴스 필드가 기본 직렬화 형태에 포함되지 않는다는 표시

• StringList를 위한 합리적인 직렬화 형태는 단순히 리스트가 포함한 문자열의 개수를 적은 다음, 그 뒤오 문자열들을 나열하는 수준이면 될 것이다. StringList의 물리적인 상세 표현은 배제한 채 논리적인 구성만 담는 것이다.
• writeObject와 readObject가 직렬화를 처리하며 StringList의 필드가 모두 transient더라도 저 둘은 각각 가장 먼저 defaultWriteObject와 defaultReadObject를 호출한다.
• 직렬화 명세는 이 작업을 무조건 해야 향후 릴리스에서 transient가 아닌 인스턴스 필드가 추가되더라도 상호 호환이 되기 때문이다.
• 이와 같은 식이라면 StringList 직렬화 형태는 원래 버전의 절반 정도의 공간을 차지하며 실행되는 속도도 두 배 정도 빠르게 수행한다.
• 스택 오버플로도 전혀 발생하지 않아 실질적으로 직렬화 할 수 있는 크기 제한이 없어졌다.

StringList에서도 기본 직렬화 형태는 비록 유연성과 성능이 떨어졌더라고, 객체를 직렬화한 후 역직렬화하면 원래 객체를 그 불변식까지 포함해 제대로 복원해낸다는 점에서 정확하다고 할 수 있지만 불변식이 세부 구현에 따라 달라지는 객체에서는 이 정확성마저 깨질 수 있다.

해시테이블을 예로 생각해보자.

• 해시테이블은 물리적으로는 키-값 엔트리들을 담은 해시 버킷을 차례로 나열한 형태다.
• 어떤 엔트리를 어떤 버킷에 감을지는 키에서 구한 해시코드가 결정하는데, 그 계산 방식은 구현에 따라 달라질 수 있다. 심지어 계산할 때마다 달라지기도 한다.
• 때문에 해시테이블을 직렬화한 후 역직렬화하면 불변식이 심각하게 훼손될 객체들이 생겨날 수 있는 것이다.

그래서 커스텀 직렬화 형태를 사용한다면, 앞서의 StringList 예에서처럼 대부분의 인스턴스 필드를 transient로 선언해야 한다.

• 기본 직렬화를 사용하면 transient 필드들은 역직렬화 될 때 기본값으로 초기화됨을 잊지 말자.
• 기본값을 그대로 사용해서는 안된다면 readObject 메서드에서 defaultReadObject를 호출한 다음, 해당 필드를 원하는 값으로 복원하자. 혹은 그 값을 처음 사용할 때 초기화 하는 방법도 있다.

private synchronized void writeObject(ObjectOutputStream s) throws IOException {
    s.defaultWriteObject();
}

sunchronized로 선언하여 스레드 안전하게 만든 객체에서 기본 직렬화를 사용하려면 writeObject도 위처럼 synchronized로 선언해야 한다.

• writeObject 메서드 안에서 동기화 하고 싶다면 클래스의 다른 부분에서 사용하는 락 순서를 똑같이 따라야 한다. 그렇지 않으면 자원 순서 교착상태에 빠질 수 있다.

이렇게 하면 직렬 버젼 UID가 일으키는 잠재적인 호환성 문제가 사라진다. 성능도 조금 빨라지는데, 직렬 버젼 UID를 명시하지 않으면 런타임에 이 값을 생성하느라 복잡한 연산을 수행하기 때문이다.

private static final long serialVersionUID = -232923283928929;

새로 작성하는 클래스에서는 어떤 long값을 선택하든 상관없다. 그냥 생각나는 아무 값이나 선택해도 된다.

직렬 버젼 UID가 없는 기존 클래스를 구버전으로 직렬화된 인스턴스와 호환성을 유지한 채 수정하고 싶다면, 구버전에서 사용한 자동 생성된 값을 그대로 사용해야 한다. 기본 버전 클래스와의 호환성을 끊고 싶다면 단순히 직렬 버전 UID값을 바꿔주면 된다.

• 클래스를 직렬화하기로 했다면 어떤 직렬화 형태를 사용할지 심사숙조 하기
• 자바의 기본 직렬화 형태는 객체를 직렬화한 결과가 해당 객체의 논리적 표현에 부합할때만 사용하고 그렇지 않다면 커스텀 직렬화 형태를 고안하라.
• 직렬화 형태도 공개 메서드를 설계할 때에 준하는 시간을 들여 설계해야 한다.
• 한번 공개된 메서드는 향후 릴리스에서 제거할 수 없듯이, 직렬화 형태에 포함된 필드도 마음대로 제거할 수 없다.
• 잘못된 직렬화 형태를 선택하면 해당 클래스의 복잡성과 성능에 영구히 부정적인 영향을 남긴다.