<T>Story <T>Story

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)을 건다 락을 건 메서드는 객체의 상태를 확인 후 필요하면 수정 즉 객체를 하나의 일관된 상태에서 다른 일관된 상태로 변화시키며 동기화를 제대로 사용하면 어떤 메서드도 이 객체의 상태가 일관되지 않은 순간을 볼 수 없다 동기화 없이는 한 스레드가 만든 변화를 다른 스레드에서 확인하지 못 할 수 있다 동기..

ITEM 77 예외를 무시하지 말라 예외를 무시하지 말라는 말은 당연한 이야기지만 사람들이 자주 어기고 있는 내용이다 API 설계자가 메서드 선언에 예외를 명시하는 이유는 그 메서드를 사용할 때 적절한 조치를 취해달라는 이야기다 API 설계자가 친절하게 써놓은 내용을 대충 듣지 말자 실제로 예외를 무시하는 일은 매우 쉽게 이루어 진다 // catch 블록을 비워버리면 예외가 무시된다 try { ... } catch (SomeException e){ } 예외는 문제 발생시 대처하는데 아주 중요한 요소인데 catch 블록을 비워두면 예외가 존재할 이유가 없다 비유하자면 화재 경보를 무시하는걸 넘어서 아예 꺼버려 다른 사람들도 화재 상황을 알지 못하게 하는 수준이다 빈 catch 블록을 목격한다면 항상 사이렌..

ITEM 76 가능한 한 실패 원자적으로 만들라 실패 원자적(failure-atomic) 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다 메서드를 실패 원자적으로 만드는 방법 가장 간단한 방법은 불변 객체로 설계하는 것 불변 객체의 상태는 생성 시점에 고정되어 절대 변하지 않기 때문에 태생부터 실패 원자적이다 가변 객체를 실패 원자적으로 만드는 방법은 작업 수행에 앞서 매개변수 유효성을 검사하는 것이다 객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성 대부분을 걸러낼 수 있다 객체의 임시 복사본에서 작업을 수행하고 작업이 성공적으로 완료되면 원래 객체와 교체하는 것 데이터를 임시 자료구조에 저장해 작업하는게 더 빠를 때 적용하기 좋다 작업 도중 발생하는 실패를 가로채는..

ITEM 75 예외의 상세 메시지에 실패 관련 정보를 담으라 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열이다 보통 예외의 클래스 이름 뒤에 상세 메세지가 붙는 구조다 이런 정보가 실패 원인을 분석해야 하는 개발자나 SRE가 얻을 수 있는 유일한 정보인 경우가 많다 더구나 실패를 재현하기 어렵다면 더 자세한 정보를 얻기가 어렵거나 불가능하다 따라서 예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 많이 담아서 반환 하는게 중요하다 사후분석을 위해 실패 순간의 상황을 정확히 포착해 예외의 상세 메세지에 담아야 한다 실패 순간을 포착하려면 발생한 예외..

ITEM 74 메서드가 던지는 모든 예외를 문서화하라 메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 아주 중요한 정보니 예외 하나하나 모두 문서화 하는게 좋다 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화 하자 공통 상위 클래스 하나로 뭉뚱그려 선언 하지 말자 극단적인 예) 메서드가 Exception, Throwable을 던진다고 선언하면 안된다 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못한다 같은 맥락에서 발생 가능한 다른 예외까지 삼켜 API 사용성을 떨어뜨린다 이 규칙의 유일한 예외는 오직 JVM만이 호출하는 main 메서드이다 자바 언어가 요구하지는 않지만 비검사 예외도 검사 예외처럼 문서화 해두면 좋다..

ITEM 73 추상화 수준에 맞는 예외를 던져라 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다 그렇지 않으면 수행하려는 일과 관련 없어 보이는 예외가 발생해 내부 구현 방식을 드러내고 윗 레벨 API를 오염시키게 된다 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 나타나 기존 클라이언트를 깨지게 할 수도 있다 예외 번역 try { ... // 저수준 추상화를 이용한다 } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역한다 throw new HigherLevelException(...); } 다음은 AbstractSequentialList에서 수행하는 예외 번역의 예다 AbstractSequentialList는 List 인터..

ITEM 72 표준 예외를 사용하라 표준 예외를 재사용하면 얻는게 많다 최고의 장점은 내가 만든 API가 다른 사람이 익히고 사용하기가 쉬워진다 많은 개발자들에게 이미 익숙해져 있는 규약을 따르기 때문 내가 만든 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다 가장 흔하게 재사용 많이 되는 예외 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을때 (null 은 따로 NPE 처리) IllegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태인 경우 NullPointerException null을 허용하지 않는 메서드에 null을 건낸경우 I..

ITEM 71 필요 없는 검사 예외 사용은 피하라 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 다르게 검사 예외는 발생한 문제를 개발자가 처리해 안정성을 높여준다 하지만 검사 예외를 과하게 쓰면 오히려 쓰기 불편한 API가 된다 어떤 메서드가 검사 예외를 던질 수 있다면 이 메서드를 호출하는 코드에서는 catch 블록을 이용해 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야된다 어느쪽이든 API 사용자에게 부담을 주며 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바8부터는 더욱 부담이 커졌다 API를 제대로 사용해도 발생할 수 있는 예외거나 개발자가 의미있는 조치..