[이펙티브 자바] 12장 : 직렬화

객체 직렬화에 대해 다뤄보자. 객체 직렬화란 자바가 객체를 바이트 스트림으로 인코딩하고(직렬화) 그 바이트 스트림으로부터 다시 객체를 재구성(역직렬화) 메커니즘이다. 직렬화된 객체는 다른 VM에 전송하거나 디스크에 저장한 후 나중에 역직렬화할 수 있다.

→ 이번 장에서는 직렬화가 품고있는 위험과 그위험을 최소화하는 방법을 알아보자.

아이템 85 : 자바 직렬화 대안을 찾으라

역직렬화를 함부로 사용하면 공격에 노출되게 된다.

직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화하지 않는 것이다.

그렇기 때문에 새로운 시스템에서 자바 직렬화를 써야 할 이유는 전혀 없다. (위험하니까)

→ 객체와 바이트 시퀀스를 변환해주는 다른 매커니즘을 사용하자.

• 다양한 플랫폼 지원
• 우수한 성능, 풍부한 지원 도구
• 자바 직렬화보다 훨씬 간단한 구조

직/역직렬화대신 속성-값 쌍 집합으로 구성된 데이터 객체를 사용함

⇒ 이 데이터 표현의 선두주자는 ‘JSON’과 프로토콜버퍼이다.

레기시 때문에 자바 직렬화를 배제할 수 없을 때

• 신뢰할 수 없는 데이터는 절대 역직렬화 하지 않는다.
• 역직렬화가 안전한지 확신이 없다면 객체 역직렬화 필터링(java.io.ObjectInputFilter)을 사용해 위험 객체를 필터링하자
  • 블랙리스트보단 화이트리스트 방식 사용하자

-핵심정리-

직렬화는 위험하니 피하자. 밑바닥부터 설계한다면 JSON 같은 대안을 사용하자. 신뢰할 수 없다면 역직렬화 자제하자.

아이템 86 : Serailizable을 구현할지는 신중히 결정하라

클래스의 인스턴스를 직렬화 가능하게 하려면 클래스 선언에 ‘implements Serializable’만 붙이면 된다. 직렬화는 간단해보이지만 훨씬 복잡하며, 값비싼 비용이 소모된다.

문제점

• Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다.
  • 이를 구현하면 ‘직렬화된 바이트 스트림 인코딩’ 또한 하나의 공개 API가 된다. (영원히 지원해야함)
  • private과 package-private 인스턴스 필드들마저 API로 공개되어 진다. (캡슐화가 깨짐)

직렬화 가능 클래스를 만들고자 한다면 처음부터 설계를 잘해야한다. 하지만 그러더라도 클래스를 개선하는 데 제약이 있다....

• 클래스의 이름, 인터페이스, 메서드 등 수정/개선사항이 생기면 직렬버전UID도 변한다. 즉, 자동생성되는 값에 의존하면 쉽게 호환성이 깨져버린다는 뜻이다.
• Serializable을 구현하면 버그와 보안 구멍이 생길 위험이 높아진다.
  • 객체는 생성자를 사용해 만드는 것이 기본인데 직렬화는 이를 우회하는 객체 생성 기법이다. 따라서 “생성자에서 구축한 불변식을 모두 보장하고 생성 도중 공격자가 객체 내부를 들여다 볼 수 없도록 해야한다"라는 규칙을 지켜야 한다. 하지만 역직렬화를 사용하면 위험에 쉽게 노출된다.
• 해당 클래스의 신버전을 릴리스할 때 테스트할 것이 늘어난다.
  • 구 인스턴스와 신 인스턴스가 역/직렬화가 가능한지 테스트 해보고 성공해야 한다.
• Serializable 구현 여부는 가볍게 결정할 사안이 아니다.
  • 단, 객체를 전송하거나 저장할 때 자바 직렬화를 이용하는 프레임워크용으로 만든 클래스라면 선택의 여지가 없다.
  • Serializable 구현에는 많은 비용이 소모되므로 클래스 설계 시 이득과 비용을 잘 저울질 해야한다.
• 상속용으로 설계된 클래스와 인터페이스 대부분은 Serializable을 확장/구현해서는 안된다.
• 만약, 확장/구현하게되면 그 클래스에게 많은 부담을 주게 된다. 하지만 Serializable구현한 클래스만 지원한다면 선택의 여지가 없다.
• 내부 클래스는 직렬화를 구현하지 말아야 한다

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

직렬화를 구현하게 되면 이후에도 버릴 수 없고 영원히 발이 묶이게 된다.

우선 고민해보고 괜찮다고 판단될 때만 기본 직렬화를 사용하라. (유연성, 성능, 정확성 측면에서 합당한지)

• 객체의 물리적 표현과 논리적 내용이 같다면 기본 직렬화 형태라도 무방하다
  • 기본 직렬화가 가능한 후보위 코드는 이름, 성, 중간이름으로 구성되며 성명의 논리적 구성요소를 정확히 반영했다. (후보 가능)
    • 위 코드에서는 readObject가 성과 이름이 null이 아님을 보장해야 한다.
    위 코드의 필드는 private이지만 직렬화로 인해 공개 API에 속하므로 문서화 해야하기 때문에 ‘@Serial’을 통해 기록했다.
  • → 형태가 적합해도 ‘불변식 보장'과 보안을 위해 readObject 메서드를 제공해야 할 때가 많다.
  • public class Name implements Serializable { /** * 성. null이 아니어야 함. * @Serial */ private final String lastName; /** * 이름. null이 아니어야 함. * @Serial */ private final String firstName; /** * 중간이름. 중간이름이 없다면 null가능. * @Serial */ private final String middleName; }

객체의 물리적 표현과 논리적 표현의 차이가 클 때 기본 직렬화 형태를 사용하면 네가지 면에서 문제가 생긴다.

• 공개 API가 현재의 내부 표현 방식에 영구히 묶인다. (이전 필드를 현재 사용하지 않더라도 지원해야함)
• 너무 많은 공간을 차지할 수 있다. (직렬화 형태가 커져서 전송/저장 속도가 느려진다)
• 시간이 너무 많이 걸릴 수 있다.
• 스택 오버플로를 일으킬 수 있다. (기본 직렬화 과정은 객체를 재귀 순회하는데 이는 규모가 있는 객체 그래프에서 스택 오버플로우를 일으킬 수 있다)

합리적인 직렬화 형태 갖춘 클래스

// 코드 87-3 합리적인 커스텀 직렬화 형태를 갖춘 StringList (462-463쪽)
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 : 직렬화에서 제외

객체의 논리적 상태와 무관한 필드라고 확신할 때만 transient 한정자를 생략해야 한다

어떤 직렬화 형태를 택하든 직렬화 가능 클래스 모두에 직렬 버전 UID를 명시적으로 부여하자

• 명시적으로 부여하면 직렬 버전 UID가 일으키는 잠재적인 호환성 문제가 사라진다. (필드에 따라 바뀌지 않으므로)

아이템 88 : readObject 메서드는 방어적을 작성하라

readObject 메서드는 public 생성자라고 생각하고 작성하자.

이 메서드는 어떤 바이트스트림이라도 유효한 인스턴스를 만들어 내야한다.

readObject 작성 지침

• private이어야 하는 객체 참조 필드는 각 필드가 가리키는 객체를 방어적을 복사하라. (불변 클래스 내 가변 요소)
• 방어적 복사 후에는 불변식 검사가 뒤따르며 이를 통과해야한다.
• 직/간접적으로 재정의할 수 있는 메서드는 호출하지 말자

아이템 89 : 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라

• readResolve 기능을 이용하면 readObject 가 만들어낸 인스턴스를 다른 것으로 대체할 수 있다.
  • 하지만, 역직렬화한 객체는 무시하고 클래스 초기화 시 만들어진 인스턴스를 반환하는 것이다.
  • 초기화 시 만들어진 인스턴스를 가져오므로 직렬화 시 실 데이터를 가질 이유가 없다 (어차피 안씀). 모든 인스턴스 필드를 transient로 선언할 것
    • transient를 안쓰면 readResolver 실행 전 역직렬화된 객체의 참조가 공격당할 수 있다. (싱글턴 파괴 가능할 수 있음)

불변식을 지키기 위해 인스턴스를 통제해야한다면 열거 타입을 사용하자.

여의치 않은 상황에서 직렬화, 인스턴스 통제가 모두 필요하다면 readResolve메서드를 작성하고 모든 참조 타입 인스턴스 필드를 transient로 선언하자.

아이템 90 : 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라

Serializable 구현 결정 이후 부터 정상 생성자 이외의 방법으로 인스턴스를 생성할 수 있게 된다. 버그 보안성 큼.

버그 보안성 위험을 줄이기 위해 ‘직렬화 프록시 패턴'을 사용한다.

바깥 클래스의 논리적 상태를 정밀하게 표현하는 중첩 클래스를 설계해 private static으로 선언한다.

이 패턴이 중요한 불변식을 안정적으로 직렬화해주는 가장 쉬운 방법이다.