Effective Java

@Override 애너테이션을 일관되게 사용하면 여러 가지 악명 높은 버그들을 예방해준다.원하는 결과는 26 이었으나, 260이 출력된다.equals를 재정의(Overriding) 한 것이 아니라 다중정의(Overloading) 한 꼴이다.equals를 @Overrid

"아무 매개변수 없이 단순히 대상에 마킹(marking)한다"는 뜻에서 마커(marker) 애너테이션이라 한다.실행결과마커 인터페이스는 일반적인 인터페이스와 동일하지만 사실상 아무 메소드도 선언하지 않은 인터페이스를 말한다.대표적인 예 - Serializable 인터페

메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족했을 때 제대로 동작해야 한다. 그리고 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다.오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발

예외는 진짜 예외적인 상황에서만 사용해야 한다.예외를 생성할 때 스택 추적 전체를 캡처하므로 비용이 만만치 않다.별도의 null 처리 코드를 추가해야 한다.null 처리를 무시하고 반환된 null은 언젠가 NullPointerException이 발생할 수 있다.null

무작위 정수 하나를 생성하고 싶을 때, 프로그래머가 직접 메소드를 만들었다고 하는 경우가 있을 것이다.코드 59-1 흔하지만 문제가 심각한 코드!n이 그리 크지않은 2의 제곱수라면 얼마 지나지 않아 같은 수열이 반복된다.n이 2의 제곱수가 아니라면 몇몇 숫자가 평균적으

코드 69-1 예외를 완전히 잘못 사용한 예 - 따라 하지 말 것!직관적이지 않다.예외를 써서 루프를 종료하는 이상한 방식으로 구현다음과 같이 표준 관융구대로 작성했다면 누구나 쉽게 이해했을 것이다.코드 - 배열을 순회하는 표준 관용구잘못된 추론을 근거로 성능을 높여보

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

클래스가 Serializable을 구현하고 기본 직렬화 형태를 사용한다면 현재의 구현에 종속적이게 된다. 즉, 기본 직렬화 형태를 버릴 수 없게 된다. 따라서 유연성, 성능, 정확성과 같은 측면을 고민한 후에 합당하다고 생각되면 기본 직렬화 형태를 사용해야 한다.일반적