직렬화는 안전하지 않다. 신뢰할 수 없는 스트림을 역직렬화하면 원격 코드 실행, 서비스 거부 등의 공격으로 이어질 수 있다. 역직렬화 과정에서 호출되어서 위험한 동작을 수행하도록 하는 메서드를 가젯이라고 하는데 이런 가젯을 여러개 사용하는 것을 가젯 체인이라고 한다.

여러 스레드가 실행 중이면 OS의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할 지를 결정한다. 정상적인 OS라면 이 작업을 공정하게 수행하지만 구체적인 스케줄링 정책은 OS마다 다를 수 있다. 따라서 잘 작성된 프로그램이라면 이 정책에 좌지우지돼서는 안 된다.정

한 메서드를 여러 스레드가 호출했을 때 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과도 같다. API 문서에서 언급이 없다면 사용자는 나름의 가정을 해야만 하고, 지나치게 동기화를 하거나 충분히 하지 못해 심각한 오류로 이어질

JAVA 5에서 도입된 동시성 유틸리티가 이전의 wait, notify로 하던 일들을 대신하게 되었다. wait과 notify는 사용하기가 아주 까다롭기 때문에 고수준 동시성 유틸리티를 사용하자.java.util.concurrent의 고수준 유틸리는 세 범주로 나눌 수

java.util.concurrent 패키지에서 간단히 작업 큐를 생성할 수 있다. 그 외에도 다양한 기능을 제공한다. 특정 태스크가 완료되기를 기다린다. 태스크 모음중 아무것 하나(nvokeAny 메서드) 혹은 모든 태스크(nvokeAll메서드) 가 완료되기를 기

과도한 동기화는 성능을 떨어뜨리고 교착상태에 빠뜨리고, 예측할 수 없는 동작을 수행한다. 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에게 양도하면 안된다.예를 들어서, 동기화된 영역 안에서는 재정의할 수 있는 메서드는

synchronized 키워드는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장한다. 많은 프로그래머들은 동기화를 배타적 실행, 즉 한 스레드가 변경하는 중이라서 상태가 일관되지않은 순간의 객체를 다른 스레드가 보지 못하게 막는 용도로만 생각한다. 먼저 이 관

API 설계자가 메서드 선언에 예외를 명시하는 까닭은 그 메서드를 사용할 때 적절한 조치를 취해달라고 말하는 것이다. 안타깝지만 예외를 무시하는 것은 아주 쉽다. 해당 메서드 호출을 try 블록으로 감싸고 catch블록에서 아무 일도 하지 않으면 된다.예외는 문제 상황

작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있는 상태라면 멋질 것이다. 검사 예외를 던진 경우라면, 호출자가 오류 상태를 복구할 수 있을 테니 특히 더 유용할 것이다. 일반화해 이야기하면, 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전

예외를 잡지못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다. 스택 추적은 예외 객체의 toString()메서드를 호출해서 얻는 문자열로, 보통은 예외의 클래스 이름 뒤에 상세 메시지가 붙는 형태다.따라서 예외

메서드가 던지는 예외는 그 메서드를 사용하는데 아주 중요한 정보다. 따라서 예외 하나하나를 문서화하는데 충분한 시간을 사용해야 한다. 검사 예외는 항상 따로 선언하고 각 예외가 발생하는 상황을 자바독의 @Throws 태그를 사용해 정확히 문서화 하자. 극단적인 예로 메

수행하려던 일과 관련 없는 예외가 튀어나온다면 당황스러울 것이다. 메서드가 저수준 예외(구체화 단계의 예외)를 처리하지 않고 바깥으로 던져버리면 내부 구현 방식을 드러내어 윗 레벨 API 를 오염시킨다. 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 튀어나와서 기존

자바 라이브러리는 쓰기에 충분한 수의 예외를 제공한다. 표준 예외를 사용하면 얻을 수 있는 가장 큰 이점은 다른 사람이 익히고 사용하기가 쉽다는 점이다. 낯선 예외를 사용하지 않아 읽기 쉽게 된다는 장점도 존재한다. 그리고, 예외 클래스가 적을수록 메모리 사용량이 줄고

검사 예외를 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 결과를 코드로 반환하거나 비검사 예외를 던지는 것과는 달리, 검사 예외는 발생한 문제를 프로그래머가 처리해 안정성을 높이게끔 해주기 때문이다. 물론, 검사예외를 과하게 사용한다면 오히려 쓰기 불편한

검사 예외는 호출하는 쪽에서 복구하리라 여겨지는 상황일 때 사용해야 한다. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서 그 메서드를 호출했을 때 발생할 수 있는 오류 상황을 API 사용자에게 알릴 수

위 코드는 잘못된 추론을 근거로 성능을 높이려고 하고 있다.JVM은 배열의 원소에 접근할 때마다 경계를 넘지 않는지 검사한다. 따라서 이 검사를 반복문에도 적용할 경우 같은 일이 중복되므로 하나를 생략한 것이다. 하지만 이 추론은 세 가지 근거에서 잘못됐다.예외는 예외

최적화는 좋은 결과보다 해로운 결과로 이어지기 쉽다. 성능때문에 견고한 구조를 희생시키지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라. 좋은 프로그램이지만 원하는 성능이 나오지 않은다면 그 아키텍처 자체가 최적화할 수 있는 길을 안내해줄 것이다. 좋은 프로그램은

자바 네이티브 인터페이스 (JNI) 는 자바 프로그램이나 C, C++ 같은 네이티브 프로그래밍 언어로 작성된 네이티브 메서드를 호출하는 기능이다. 네이티브 메서드의 주요 기능은 다음과 같다.레지스트리 같은 플랫폼 특화 기능 사용네이티브 코드로 작성된 기존 라이브러리 사

리플렉션 리플렉션을 사용하면 프로그램,에서 임의의 클래스에 접근할 수 있다. Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있고, 이어서 이 인스턴스들로 그 클래스의 멤버

\[아이템51]에서 매개변수 타입으로 클래스가 아닌 인터페이스로 사용하라고 했었다. 이 조언은 "객체는 클래스가 아닌 인터페이스로 참조하라"고까지 확장할 수 있다. 적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라.