<T>Story <T>Story

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 같은 표준 컬렉션 인터페이스에 동시성을 가미해 구현한 고성능 컬렉션이다 높은 동시성에 도달하기 위해 동기화를 각자의 내부에서 수행한다 동시성 컬렉션에서 동시성을 무시력화하는 건 불가능하며 외..

ITEM 80 스레드보다는 실행자, 태스크, 스트림을 애용하라 실행자 프레임워크(Executor Framework) 인터페이스 기반의 유연한 태스크 실행 기능 java.util.concurrent 패키지에 담겨있다초판의 코드보다 모든 면에서 뛰어난 작업 큐를 단 한줄로 생성 가능해졌다 ExecutorService exec = Executors.newSingleThreadExecutor(); 이 실행자가 실행할 태스크(작업)를 넘기는 방법이다 exec.execute(runnable); 실행자를 우아하게 종료시키는 방법(이 작업이 실패하면 VM 자체가 종료되지 않는다) exec.shutdown(); 큐를 둘 이상의 스레드가 처리하게 하고 싶다면 간단히 다른 정적 팩터리를 이용하여 다른 종류의 실행자 서비스(..

ITEM 79 과도한 동기화는 피하라 과도한 동기화는 성능을 떨어뜨리고 교착상태에 빠뜨리고 예측할 수 없는 동작을 낳기도 한다 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안 된다 동기화된 영역 안에서는 재정의할 수 있는 메서드는 호출하면 안된다 클라이언트가 넘겨준 함수 객체를 호출해서도 안된다 동기화된 영역을 포함한 클래스 관점에서는 이런 메서드는 다른 차원에서 온 외계인이다 그 메서드가 무슨 일을 할지 알지 못하며 통제할 수도 없다는 뜻이다 외계인 메서드(alien method)가 하는 일에 따라 동기화된 영역은 예외를 일으키거나 교착상태에 빠지거나 데이터를 훼손할 수도 있다 열린 호출(open call) 동기화 영역 바깥에서 호출되는 외..

ITEM 78 공유 중인 가변 데이터는 동기화해 사용하라 synchronized 키워드는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장한다 많은 개발자가 동기화를 배타적 실행 용도로 생각한다 한 스레드가 변경하는 중이라 상태가 일관되지 않은 순간의 객체를 다른 스레드가 보지 못하게 막는 용도로만 생각한다 한 객체가 일관된 상태를 가지고 생성 해당 객체에 접근하는 메서드는 그 객체에 락(lock)을 건다 락을 건 메서드는 객체의 상태를 확인 후 필요하면 수정 즉 객체를 하나의 일관된 상태에서 다른 일관된 상태로 변화시키며 동기화를 제대로 사용하면 어떤 메서드도 이 객체의 상태가 일관되지 않은 순간을 볼 수 없다 동기화 없이는 한 스레드가 만든 변화를 다른 스레드에서 확인하지 못 할 수 있다 동기..