아이템 86. Serializable 을 사용할 지는 신중히 결정하라

[corock]

도입

• 무지성 class Xxx implements Serializable? ❌
• 직렬화 지원은 짧게 보면 쉬워 보이지만, 장기적으로 보면 피곤한 일로 돌아올 수 있음

직렬화(serialization)란?

(자바) 객체 데이터를 바이트 스트림으로 인코딩하는 것

역직렬화(deserialization)란?

바이트로 변환된 데이터를 다시 객체로 변환하는 것

Serializable 구현의 문제점

1. 릴리스한 뒤에는 수정하기 어려움
2. 버그와 보안 구멍이 생길 위험 ⬆️
3. 해당 클래스의 신버전을 릴리스할 때 테스트할 것이 늘어남

릴리스한 뒤에는 수정하기 어려움

• Serializable 인터페이스를 구현하면 직렬화된 바이트 스트림 직렬화 형태도 하나의 공개 API 가 됨
  • 즉, 해당 클래스를 오랫동안 널리 사용된다면 그 직렬화 형태도 영원히 Support 해야 함
• 만약 커스텀 직렬화 형태를 설계하지 않고 자바의 기본 방식을 사용하면 직렬화 형태는 최소 적용 당시 클래스의 내부 구현 방식에 영원히 묶임
  • 즉, 기본 직렬화 형태에서는 private 와 package-private 필드마저 공개 API 가 되어, 캡슐화에 위배되는 셈
• 필드로의 접근을 최대한 막는 정보 은닉도 무력화시킴 (feat. 아이템 15. 클래스와 멤버의 접근 권한을 최소화 하라 #41)
• 뒤늦게 클래스 내부 구현을 손보면 기존 직렬화 형태와 달라질 수 있음
  • 한쪽은 구버전 인스턴스를 직렬화하고 다른 쪽은 신버전 클래스로 역직렬화할 수도 있음
  • ObjectOutputStream.putFields 와 ObjectOutputStream.readFields 로 기존 직렬화 형태를 유지하면서 내부 표현을 바꿀 수는 있음
    • 하지만 어려움
    • 소스 코드가 지저분해짐

그럼에도 불구하고, 직렬화 가능 클래스를 만들고 싶다면~?

• 고품질의 직렬화 형태도 주의해서 함께 설계해야 함
• feat. 아이템 87. 커스텀 직렬화 형태를 고려해보라
• feat. 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 #203

만약 직렬화 형태를 제임스 고슬링 옹이 설계한다면~?

• 사람인지라 직렬화 형태를 잘못 설계했다면 카오스(chaos) 개방
• 자바 구루가 직렬화 형태를 잘 설계하더라도 클래스를 개선하는데 제약이 될 수 있음
  • e.g. 스트림 고유 식별자 (serial version UID)
  • 자동 생성되는 값에 의존할 경우 호환성이 깨져 런타임 시 InvalidClassException 예외가 발생할 수 있음

버그와 보안 구멍이 생길 위험 ⬆️

• 사실 어떻게 보면 직렬화는 또다른 객체 생성 기법 중 하나임
  • 직렬화는 언어의 기본 메커니즘을 우회하는 녀석
• 기본 방식을 따르든 재정의해 사용하든, 역직렬화는 일반 생성자의 문제가 그대로 적용되는 "숨은 생성자"
  • 이 숨은 생성자는 "생성자에서 구축한 불변식을 모두 보장해야 하고 생성 도중 공격자가 객체 내부를 들여다볼 수 없도록 해야 한다" 를 잊기 쉬움
  • feat. 아이템 88. readObject 는 방어적으로 작성하라

해당 클래스의 신버전을 릴리스할 때 테스트할 것이 늘어남

• 직렬화 가능 클래스가 수정되면 신버전 인스턴스 직렬화한 후 구버전으로 역직렬화 가능 여부(반대 방식 포함) 테스트가 필요함
• 양방향 직렬화/역직렬화가 모두 성공하고, 원래의 객체를 충실히 복제해내는지를 반드시 확인해야 함
  • 클래스를 처음 제작할 때 커스텀 직렬화 형태를 잘 설계해놨다면 이러한 테스트 부담을 줄일 수 있음
  • feat. 아이템 87. 커스텀 직렬화 형태를 고려해보라
  • feat. 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 #203

Serializable 구현의 이득과 비용

• 클래스를 설계할 때마다 이득과 비용을 잘 저울질해야 함
• 역사적으로 '값' 클래스와 컬렉션 클래스들은 Serializable 구현
  • e.g. BigInteger, Instant
• 역사적으로 '동작' 하는 객체를 표현하는 클래스들은 구현하지 않음
  • e.g. thread pool

Serializable 구현을 하면 안되는 것들

1. 상속용으로 설계된 클래스
2. 대부분의 인터페이스
3. 내부 클래스(inner class)

상속용으로 설계된 클래스

• e.g. Throwable, Component
  • Throwable: 서버가 RMI 를 통해 클라이언트로 예외를 보내기 위해 구현
  • Component: GUI 를 전송하고 저장하고 복원하기 위해 구현
• feat. 아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 #45

대부분의 인터페이스

• 상속용으로 설계된 클래스�를 포함해서 Serializable 인터페이스를 구현한 녀석들을 활용하는 대상에게 큰 부담을 줌

내부 클래스(inner class)

• 바깥 인스턴스 참조와 유효 범위 내 지역변수 값들을 저장하기 위해 컴파일러가 생성한 필드가 자동으로 추가됨
  • 익명 클래스와 지역 클래스의 이름 명명 규칙이 언어 명세가 없음
  • 이 컴파일러가 생성한 필드가 클래스 정의에 어떻게 추가되는지도 정의되지 않음
  • 즉, 내부 클래스에 대한 기본 직렬화 형태가 분명하지 않음
• 단, 정적 멤버 클래스는 Serializable 을 구현해도 됨
• cf. 아이템 24. 멤버 클래스는 되도록 static으로 만들라 #48

클래스 필드가 직렬화와 확장이 모두 가능할 시 주의사항

1. 필드 중 불변식을 보장해야 할 게 있다면 반드시 하위 클래스에서 finalize 메서드를 재정의하지 못하게 해야 함
   • 본인이 재정의해서 final 로 선언
   • 이렇게 해두지 않으면 finalizer 공격을 당할 수 있음 (feat. 아이템 8. finalizer와 cleaner 사용을 피하라 #22)
2. 필드 중 기본값으로 초기화 시 위배되는 불변식이 있다면 클래스에 반드시 readObjectNoData 메서드를 추가해야 함
   • readObjectNoData 메서드는 자바 4부터 추가, 직렬화 가능 클래스에 직렬화 가능 상위 클래스를 추가하는 드문 경우를 위한 메서드

    private void readObjectNoData() throws InvalidObjectException {
        throw new InvalidObjectException("스트림 데이터가 필요합니다");
    }

Serializable 인터페이스를 구현하지 않기로 할 때 주의사항

1. 매개변수가 없는 생성자를 제공하지 말 것
   • 상속용 클래스인데 직렬화를 지원하지 않으면 그 하위 클래스에서 직렬화를 지원하려 할 때 부담 ⬆️
   • 보통 이런 클래스를 역직렬화하려면 그 상위 클래스는 매개변수가 없는 생성자를 제공해야 함
   • 제공하지 않으면 하위 클래스는 어쩔 수 없이 직렬화 프록시 패턴을 사용해야 함
     • feat. 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 #203

회고

• 직렬화 관련 컴파일 오류가 발생하면 가볍게 implement Serializable 코드를 추가했었는데, 가볍게 여길 사항이 아니었다.

References

• 자바 직렬화, 그것이 알고싶다. 훑어보기편
• 자바 직렬화, 그것이 알고싶다. 실무편