<T>Story <T>Story

ITEM 90 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 Serializable을 구현하기로 결정한 순간 언어의 정상 메커니즘인 생성자 이외의 방법으로 인스턴스 생성이 가능해진다 버그와 보안 문제가 일어날 가능성이 커진다 직렬화 프록시 패턴을 사용하면 버그와 보안 문제가 줄어든다 적절한 프록시 패턴은 별로 복잡하지 않다 바깥 클래스의 논리적 상태를 정밀하게 표현하는 중첩 클래스를 설계해 private static으로 선언한다 이 중첩 클래스가 바로 바깥 클래스의 직렬화 프록시다 중첩 클래스의 생성자는 단 하나여야 하며 바깥 클래스를 매개변수로 받아야 한다 이 생성자는 단순히 인수로 넘어온 인스턴스의 데이터를 복사한다 일관성 검사나 방어적 복사도 필요 없다 설계상 직렬화 프록시의 기본 직렬화 형..

ITEM 89 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거 타입을 사용하라 바깥에서 생성자를 호출하지 못하게 막는 방식으로 싱글턴을 보장한 코드 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { .. } public void leaveTheBuilding() { .. } } 위 코드는 클래스 선언에 implements Serializable을 추가하면 더이상 싱글턴이 아니게 된다 기본 직렬화를 쓰지 않더라도, 명시적인 readObject를 제공하더라도 소용 없다 어떤 readObject를 사용하든 이클르새가 초기화될 때 만들어진 인스턴스와는 별개인 인스턴스를 반환하게 된다 re..

ITEM 88 readObject 메서드는 방어적으로 작성하라 객체를 역직렬화할 때는 클라이언트가 소유해서는 안 되는 객체 참조를 갖는 필드를 모두 반드시 방어적으로 복사해야 한다 readObject 메서드를 작성할 때는 언제나 public 생성자를 작성하는 자세로 임하자 readObject는 어떤 바이트 스트림이 넘어오더라도 유효한 인스턴스를 만들어내야 한다 바이트 스트림이 진짜 직렬화된 인스턴스라고 가정해서는 안 된다 여기서는 기본 직렬화 형태를 사용한 클래스를 예로 들었지만 커스텀 직렬화를 사용하더라도 모든 문제가 그대로 발생할 수 있다 안전한 readObject 메서드를 작성하는 지침 private이어야 하는 객체 참조 필드는 각 필드가 가리키는 객체를 방어적으로 복사하라 불변 클래스 내의 가변 ..

ITEM 87 커스텀 직렬화 형태를 고려해보라 먼저 고민해보고 괜찮다고 판단될 때만 기본 직렬화 형태를 사용하라 기본 직렬화 형태는 유연성, 성능, 정확성 측면에서 신중히 고민한 후 합당할 때만 사용해야 한다 어떤 객체의 기본 직렬화 형태는 그 객체를 루트로 하는 객체 그래프의 물리적 모습을 나름 효율적으로 인코딩 한다 객체가 포함한 데이터와 그 객체부터 시작해 접근할 수 있는 모든 객체를 담아내고 이 객체들이 연결된 위상까지 기술한다 이상적인 직렬화 형태면 물리적인 모습과 독립된 논리적인 모습만 표현해야 한다 객체의 물리적 표현과 논리적 내용이 같다면 기본 직렬화 형태라도 무방하다 사람의 성명을 간략하게 표현한 코드 기본 직렬화 형태를 써도 괜찮다 public class Name implements S..

ITEM 86 Serializable을 구현할지는 신중히 결정하라 클래스의 인스턴스를 직렬화가 가능하게 하려면 Serializable을 구현하면 된다 쉽게 적용 가능하기 때문에 개발자가 특별히 신경 쓰지 않아도 된다고 생각 할 수 있지만 사실은 훨씬 더 복잡하다 직렬화를 지원하는게 짧게 보면 쉬워 보이지만 길게 보면 아주 값 비싼 일이다 Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다 클래스가 Serializable을 구현하면 직렬화된 바이트 스트림 인코딩도 하나의 공개 API가 된다 클래스가 많이 사용되게 되면 그 직렬화 형태도 다른 공개 API 처럼 영원히 지원해야 하는 것이다 커스텀 직렬화 형태를 설계하지 않고 자바의 기본 방식을 사용하면 직렬화 형태는 최소 적용 당시 클래스의 내..

ITEM 85 자바 직렬화의 대안을 찾으라 직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화하지 않는것이다 신뢰할 수 없는 바이트 스트림을 역직렬화 하는게 스스로를 공격에 노출하는 행위다 객체와 바이트 시퀀스를 변환해주는 다른 메커니즘이 많이 있기 때문에 우리가 작성하는 코드에 자바 직렬화를 써야 할 이유가 없다 이 방식들은 자바 직렬화의 여러 위험을 회피하면서 다양한 플랫폼 지원, 우수한 성능, 풍부한 지원 도구, 활발한 커뮤니티와 전문가 집단 등 수많은 이점을 제공한다 이 표현들은 자바 직렬화보다 훨씬 간단하며 임의 객체 그래프를 자동으로 직렬화,역직렬화 하지 않는다 대신 속성-값 쌍의 집합으로 구성된 간단하고 구조화된 데이터 객체를 사용하며 기본타입 몇개와 배열타입만 제공할 뿐이다 위와 같..

ITEM 84 프로그램의 동작을 스레드 스케줄러에 기대지 말라 여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다 정상적인 운영체제라면 이 작업을 공정하게 수행하지만 구체적인 스케쥴링 정책은 운영체제마다 다를 수 있다 따라서 잘 작성된 프로그램이라면 이 정책에 좌지우지 돼서는 안 된다 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다 빠르고 견고하며 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것 이렇게 해야 스레드 스케쥴러가 고민할 거리가 줄어든다 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만들자 이..

ITEM 83 지연 초기화는 신중히 사용하라 지연 초기화(lazy initialization)는 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법이다 값이 전혀 쓰이지 않으면 초기화도 결코 일어나지 않는다 이 기법은 정적 필드와 인스턴스 필드 모두에 사용할 수 있다 지연 초기화는 주로 최적화 용도로 쓰이며 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다 다른 모든 최적화와 마찬기로 필요할 때까지는 하지 않는게 좋으며 지연초기화는 양날의 검이다 클래스 혹은 인스턴스 생성시 초기화 비용은 줄지만 그 대신 지연 초기화하는 필드에 접근하는 비용은 커진다 지연 초기화하려는 필드 중 결국 초기화가 이뤄지는 비율, 실제 초기화에 드는 비용, 초기화된 각 필드를 얼마나 빈번히..

ITEM 82 스레드 안정성 수준을 문서화하라 한 메서드를 여러 스레드가 동시에 호출할 때 그 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다 API 문서에서 아무런 언급도 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다 만약 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나 지나치게 한 상태일 것이며 두 경우 모두 심각한 오류로 이어질 수 있다 API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다는 이야기가 있다 이건 몇가지 이유로 틀린 이야기이다 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈..

ITEM 81 wait와 notify보다는 동시성 유틸리티를 애용하라 wait와 notifiy는 올바르게 사용하기가 아주 까다로우니 고수준 동시성 유틸리티를 사용하자 java.util.concurrent의 고수준 유틸리티는 세 범주로 나눌 수 있다 실행자 프레임워크, 동시성 컬렉션(concurrent collection), 동기화 장치(synchronizer) 실행자 프레임워크는 item80에서 가볍게 알아 보았고 이번 item에서는 동시성 컬렉션과 동기화 장치를 알아본다 동시성 컬렉션 List, Queue, Map 같은 표준 컬렉션 인터페이스에 동시성을 가미해 구현한 고성능 컬렉션이다 높은 동시성에 도달하기 위해 동기화를 각자의 내부에서 수행한다 동시성 컬렉션에서 동시성을 무시력화하는 건 불가능하며 외..