개발공부블로그

Serializable 인터페이스를 구현하겠다는 결정을 내리게 되면 버그나 보안 결함이 생길 가능성이 높다. 하지만 이런 위험을 크게 줄일 수 있는 기술이 하나 있다. 직렬화 프락시 패턴이라고 알려진 기법이다.

 우선 바깥 클래스 객체의 논리적 상태를 간결하게 표현하는 직렬화 가능 클래스를 private static 중첩 클래스로 설계한다. 이 중첩클래스를 직렬화 프락시라고 부르는데, 바깥 클래스를 인자 자료형으로 사용하는 생성자를 하나만 가진다. 이 생성자는 인자에서 데이터를 복사하기만 한다. 일관성 검사를 할 필요도 없고, 방어적 복사를 할 필요도 없다.

 아래는 Period 클래스의 프락시 코드이다.

선언부에 "implements Serializable"을 붙이는 순간 이 클래스는 더 이상 싱글턴 클래스가 아니다. readObject 메서드는 새로 생성된 객체를 반환하는데, 이 객체는 클래스가 초기화될 당시에 만들어진 객체와 같은 객체가 아니다.  readResolve를 이용하면 readObject가 만들어낸 객체를 다른 것으로 대체할 수 있다. 역지렬화가 끝나서 만들어진 객체에 대해 이 메서드가 호출되는데, 새로 만들어진 객체 대신, 이 메서드가 반환하는 객체가 사용자에게 반환된다는 것이다. 

 싱글턴 객체처럼, 개체 통제를 위해 readResolve를 활용할 때는, 객체 참조 자료형으로 선언된 모든 객체 필드를 반드시 transient로 선언해야 한다. 이러한 규칙을 지키지 않으면 아래의 오류가 발생할 수 있디/

 하지만 readResolve 메서드가 실행되기 전에 역직렬화된 객체에 대한 참조를 가로 칠 수 있게된다.

readObject 메서드가 실질적으로는 public 생성자나 마찬가지다. 생성자를 구현할 떄와 같은 점에 주의해야 한다는 것이다. 생성자와 마찬가지로 인자의 유혀성을 검사해야 하고 필요하다면 인자를 방어적으로 복사해야 한다. 

 즉, readObject는 바이트 스트림을인자로 받는 생성자다. 문제는 인공적으로 만들어진 바이트 스트림을 readObject에 인자로 넘길 때 생긴다. 클래스 불변식을 위반하는 객체를 만들어 낼 수 있게 되는 것이다. 

요약

Serializable을 구현한 클래스를 만들면서 기본 직렬화 형식을 그대로 이용하면, 기존 구현을 완전히 내버리기란 불가능해진다. 그 직렬화 형식에 영원히 갇히게 된다는 뜻이다. 어떤 직렬화 형ㅅ힉이 적절할지 따져보지도 않고 기본 직렬화 형식을 그대로 받아들이지 말아야 한다. 

 기본 직렬화 형식은 그 객체의 물리적 표현이 논리적 내용과 동일할 때만 적절하다. 예를 들어 아래의 클래스를 보자.

Serializable 구현과 관련된 가장 큰 문제는 일단 클래스를 릴리즈하고 나면 클래스 구현을 유연하게 바꾸기 어려워진다는 것이다. Serializable을 구현하면 그 클래스의 바이트 스트림 인코딩(직렬화방식)도 공개 API의 일부가 되어 버린다. 사용자 정의 직렬화형식을 설계하지 않고 기본 형식을 그대로 이용할 경우, 직렬화 형식은 영원히 클래스의 원래 내부 표현방식에 종속된다. 다시 말해, 기본 직렬화 형식을 받아 들이면 그 클래스의  private와 pacakage-private 객체 필드도 공개 API가 된다는 것이다. 정보은닉을 위해 필드의 접근 권한은 최소화해야 한다는 원칙은 효력을 잃게 된다.

Serialiable을 구현하는 생기는 두 번째 문제는, 버그나 보안 취약점이 발생할 가능성이 높다는 것이다. 보통 객체는 생성자를 통해 생성한다. 직렬화는 언어 외적인 객체 생성 메커니즘이다. 역직렬화는 생성자와 동일한 이슈를 갖고 있는 "숨은 생성자"다. 역직렬화 과정에 관계된 생성자가 명시적으로 존재하지 않기 때문에 생성자가 만족하는 모든 불변식을 보장해야 하는데, 일반적으로 이러한 과정을 놓치는 경우가 많다. 

Serializable을 구현하는 생기는 세 번째 문제는, 새 버전 클래스를 내놓기 위한 테스트 부담이 늘어난다. 직렬화 가능 클래스를 수정할 때는, 새 릴리즈에서 만들고 직렬화한 객체를 예전 릴리즈에서 역직렬화할 수 있는지, 그 역도 가능한지 검사하는 것이 중요하다. 또한 객체 원래의 기능도 문제가 없는지 테스트해봐야 한다. 

계승을 염두에 두고 설계하는 클래스는 Serializable을 구현하지 않는 것이 바람직하다. 또한 인터페이스는 가급적 Serializable을 계승하지 말아야 한다.

내부 클래스는 Serializable 을 구현하는 안된다. 내부 클래스에는 바깥 객체에 대한 참조를 보관하고 바깥 유효범위의 지연 변수 값을 보관하기 위해 컴파일러가 자동으로 생성하는 인위생성 필드가 있다. 익명클래스나 지역 클래스 이름과 마찬가지로, 언어 명세서에는 이런 필드가 클래스 정의에 어떻게 들어 맞는지 나와있지 않다. 따라서 내부 클래스의 기본 직렬화 형식은 정의될 수 없다. 인위생성 필드 때문에 ..? 

실행할 스레드가 많을 때, 어떤 스레드를 얼마나 오랫동안 실행할지 결정하는 것은 스레드 스케줄러다. 제대로 된 운영체제라면 공평한 결정을 내리려 애쓰겠지만, 그 정책은 바뀔 수 있다. 따라서 좋은 프로그램이라면 스케줄링 정책에는 의존하지 말아야 한다 정확성을 보장하거나 성능을 높이기 위해 스레드 스케줄러에 의존하는 프로그램은 이식성이 떨어진다.

 그렇다면 스케줄러에 의존성을 낮으면서 이식성이 좋은 프로그램은 어떻게 개발하여야 할까? 실행 가능 스레드의 평균적 수가 프로세서 수보다 너무 많아지지 않도록 하는 것이다. 그렇게 했을 때 스레드 스케줄러가 할 수 있는 일이라고는 그저 더 이상 실행할 수 없을 때까지 실행 가능한 스레드를 실행하는 것뿐이다. 

 실행 가능 스레드의 갯수를 최소한으로 유지하려면 어떻게 해야할까? 그것은 스레드가 필요한 일을 하고 나서 다음에 할 일을 기다리게 만드는 것이다. 스레드는 필요한 일을 하고 있지 않을 때는 실행 중이어서는 안된다. 

요약

초기화 지연은 필드 초기화를 실제로 그 값이 쓰일 때까지 미루는 것이다. 값을 사용하는 곳이 없다면 필드는 결코 초기화되지 않을 것이다. 초기화 지연은 기본적으로 최적화 기법이지만, 객체 초기화 과정에서 발생하는 해로우 순환성을 해소하기 위해서도 사용된다. 

 초기화 지연 기법이 어울리는 곳이 따로 있다. 필드 사용 빈도가 낮고 초기화 비용이 높다면 쓸만할 것이다. 다중 스레드 환경에서 초기화 지연 기법을 구현하는 것은 까다롭다. 두 개 이상의 스레드가 그런 필드를 공유할 때는 반드시 적절한 동기화를 해주어야 한다. 

아래는 초기화 순환성 문제를 해소하기 위해서 동기화된 접근자를 사용한 초기화 기법이다.