이펙티브자바

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 Serializable을 구현하면, 언어의 정상 메커니즘인 생성자 이외의 방법으로 인스턴스를 생성할 수 있다. 버그와 보안 문제가 일어날 가능성이 커진다는 뜻이지만, 이 위험을 크게 줄여줄 기법이 있는데 이를 ‘직렬화 프록시 패턴’ 이라고 한다. 직렬화 프록시 패턴 바깥 클래스의 논리적 상태를 정밀하게 표현하는 중첩 클래스를 설계해 private static으로 선언한다. 이 중첩 클래스가 바로 바깥 클래스의 직렬화 프록시이다. 중첩 클래스의 생성자는 단 하나여야 하며, 바깥 클래스를 매개변수로 받아야 한다. 이 생성자는 단순히 인수로 넘어온 인..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 89. 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거 타입을 사용하라 ex 1) 생성자 호출을 막은 싱글턴 패턴 예시 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public void leaveTheBuilding() { ... } } 이 클래스는 바깥에서 생성자를 호출하지 못하게 막는 방식(private)으로 인스턴스가 오직 하나만 만들어짐을 보장했다. 아이템 3에서 이야기했듯 이 클래스는 선언에 implements Serializable을 추가하는 순간 싱글턴이..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 88. readObject 메서드는 방어적으로 작성하라 ex 1) 방어적 복사를 사용하는 불변 클래스 예시 public final class Period { private final Date start; private final Date end; /** * @param start 시작 시각 * @param end 종료 시각; 시작 시각보다 뒤여야 한다. * @throws IllegalArgumentException 시작 시각이 종료 시각보다 늦을 때 발생한다. * @throws NullPointerException start나 end가 null이면 발생한다. */ public Period(Date star..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 86. Serializable을 구현할지는 신중히 결정하라 어떤 클래스의 인스턴스를 직렬화할 수 있게 하려면 클래스 선언에 implements Serializable만 덧붙이면 된다. Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다. 클래스가 Serializable을 구현하면 직렬화된 바이트 스트림 인코딩도 하나의 공개 API가 되며, 이 클래스가 널리 퍼지는 경우 그 직렬화 형태도 영원히 지원해야 한다. 커스텀 직렬화 형태를 설계하지 않고 자바의 기본 방식을 사용하면 직렬화 형태는 최소 적용 당시 클래스의 내부 구현 방식에 묶인다. 즉, 기본 직렬화 형태에서는 클래스의 private과 ..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 85. 자바 직렬화의 대안을 찾으라 직렬화 객체 직렬화 : 자바가 객체를 바이트 스트림으로 인코딩(직렬화)하고, 그 바이트 스트림으로부터 다시 객체를 재구성(역직렬화)하는 매커니즘이다. 직렬화된 객체는 다른 VM에 전송하거나 디스크에 저장한 후 필요할 때 역직렬화하여 사용할 수 있다. 자바의 직렬화 자바의 직렬화는 위험하다. (보이지 않는 생성자, API와 구현 사이의 모호해진 경계, 잠재적인 정확성 문제, 성능, 보안, 유지보수성 등) 직렬화의 근본적인 문제는 공격 범위가 너무 넓고 지속적으로 더욱 넓어져 방어하기 어렵다는 것이다. ObjectInputStream의 readObject 메서드를 호출하면서..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라 여러 스레드가 실행 중이면 OS의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할 지 정한다. 운영체제마다 구체적인 스케줄링 정책은 다를 수 있기 때문에, 이 정책에 의존하면 안된다. 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. 좋은 프로그램을 만드는 Tip 실행 가능한 스레드의 평균 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다. 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 하자. 이러면 스레드 스케줄링 정책이 다르더라도 크게 지장받지 않는다. 실행 가능한 ..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 83. 지연 초기화는 신중히 사용하라 지연 초기화(lazy initialization) 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법 값이 전혀 쓰이지 않으면, 초기화도 절대 일어나지 않는다. 정적 필드와 인스턴스 필드 모두 적용 가능하다. 주로 최적화 용도로 쓰이지만, 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다. 지연 초기화는 양날의 검이다. 클래스 혹은 인스턴스 생성 시 초기화 비용은 줄어들지만 지연 초기화하는 필드에 접근하는 비용은 커진다. 지연 초기화를 하는 필드 중 결국 초기화가 이뤄지는 비율에 따라, 실제 초기화에 드는 비용에 따라, 초기화된 ..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 82. 스레드 안정성 수준을 문서화하라 한 메서드를 여러 메서드가 동시에 호출할 때 그 메서드가 어떻게 동작하는 지는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 정보이다. API 문서에서 아무런 언급도 없으면 그 클래스 사용자는 그 관계에 대해 추측해야하며, 추측이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나 지나치게 한 상태로 오류가 발생할 수 있다. synchronized API 문서에 synchronized 한정자가 있는 메서드는 안전하다고도 하는데, 몇 가지 이유로 틀렸다. JavaDoc이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다..