구르는 돌에는 이끼가 끼지 않는다

toString을 항상 재정의하라

Object의 기본 toString 메서드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없음

toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉬음

실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋음

포맷을 명시하든 아니든 여러분의 의도는 명확히 밝혀야 함

class sample(){

    @Override public String toString(){
        return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
    }

}

class sample(){

    @Override public String toString(){
        ...
    }

}

포맷 명시 여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자
PhoneNumber 클래스는 지역 코드, 프리픽스, 가입자 번호용 접근자를 제공해야함
그렇지 않으면 이 정보가 필요한 프로그래머는 toString의 반환값을 파싱할 수 밖에 없음

정적 유틸리티 클래스, 대부분의 열거 타입 이미 toString을 제공함

하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 함
대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString 메서드를 상속해 씀

구글의 AutoValue 프레임워크는 toString도 생성해줌

정리

모든 구체 클래스에서 Object의 toString을 재정의하자.

toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야함

equals를 재정의하려거든 hashCode도 재정의하라

hashCode 일반 규약을 어기에 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제

논리적으로 같은 객체는 같은 해시코드를 반환해야함

class example() {

    public static void main(String[] args) {
        Map<PhoneNumber, String> m = new HashMap<>();
        m.put(new PhoneNumber(707, 867, 5309), "제니");    
    }

}

위 코드에서 m.get(new PhoneNumber(707, 867, 5309))를 실행하면 "제니"가 나와야함
하지만, null을 반환함

PhoneNumber 클래스는 hashCode를 재정의하지 않았기 때문에 논리적 동치인 두 객체가
서로 다른 해시코드를 반환하여 두번째 규약을 지키지 못함

백기선님 강의 example

https://github.com/jshag90/effective-java-study/blob/main/src/main/java/com/ji/effective/java/chapter2/item11/hashtable/HashMapTest.java

최악의 (하지만 적법한) hashCode 구헌 - 사용 금지!

class sample(){

    @Override public int hashCode(){return 42;}
}

위와 같이 정의하면 모든 객체에서 똑같은 해시코드를 반환
해시테이블의 버킷 하나에 담겨 마치 연결 리스트 처럼 동작한다.

그 결과 평균 수행 시간이 O(1)인 해시테이블이 O(n)으로 느려져서 객체가 많아지면 도저기 쓸수 없게 된다.

곱한 숫자를 31로 정한 이유는 31이 홀수이면서 소수(prime)이기 때문임
소수를 곱하는 이유는 명확하지 않지만 정통적으로 그리해왔다.
결과적으로 31을 이용하면, 이 곱셈을 시프트 연산과 뺄셈으로 대체해 최적화할 수 있음
요즘 VM들은 이런 최적화를 자동으로 해줌

31이라는 숫자를 사용했을 때 가장 해시 충돌이 적었다고함

전형적인 hashCode 메서드

class sample(){
    @Override public int hashCode(){
        int result = Short.hashCode(areaCode);
        result = 31 * result + Short.hashCode(prefix);
        result = 31 * result + Short.hashCode(lineNum);
        return result;
    }
}

한 줄짜리 hashCode 메서드 - 성능이 살짝 아쉽다.

class sample(){
    @Override public int hashCode(){
        return Object.hash(lineNum, prefix, areaCode);
    }
}

hash 메서드는 성능에 민감하지 않은 상황에서만 사용하자.

클래스가 불변이고 해시코드를 계산하는 비용이 크다면, 매번 새로 계산하기보다는 캐싱하는 방식으로 고려해야함

해시의 키로 사용되지 않는 경우라면 hashCode가 처음 불릴 때 계산하는 지연 초기화(lazy initialization) 전략을 고려
(생성자에서 미리 계산하는게 아니라 hashCode()가 호출 되었을 때 값을 초기화)

해시코드를 지연 초기화하는 hashCode 메서드 - 스레드 안정성까지 고려해야 함

class Sample(){
    private int hashCode; // 자동으로 0으로 초기화됨

    @Override public int hashCode(){
        int result = hashCode;
        if(result == 0){
            int result = Short.hashCode(areaCode);
            result = 31 * result + Short.hashCode(prefix);
            result = 31 * result + Short.hashCode(lineNum);
            hashCode = result;
        }

        return result;
    }

}

성능을 높인답시고 해시코드를 계산할 때 핵심 필드를 생략해서는 안됨
특히 어떤 필드는 특정 영역에 몰른 인스턴스들의 해시코드를 넓은 범위로 고르게 퍼트려주는 효과가 있을 수 있음
핵심 필드가 없다면 수많은 인스턴스가 단 몇 개의 해시코드로 집중되어 해시테이블의 속도가 선형으로 느려짐

정리

equals를 재정의할 때는 hashCode도 반드시 재정의 해야함

hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며,
서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 규현해야함

AutoValue 프레임워크를 사용하면 멋진 equals와 hashCode를 자동으로 만들어줌

추가 정리

스레드 안전

https://github.com/jshag90/effective-java-study/blob/main/src/main/java/com/ji/effective/java/chapter2/item11/hashcode/PhoneNumber.java

1. 스택

스택을 간단히 구현한 코드

메모리 누수가 일어나는 위치가 어디인가?

public class Stack {
    private Object[] elements; 
    private int size =0; 
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack(){
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e){
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop(){
        if(size == 0)
            throw new EmptyStackException();
        return elements[--size];
    }

    private void ensureCapacity(){
        if(elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }

}

스택을 사용하는 프로그램을 오래 실행하다 보면 점차 가비지 컬렉션 활동과 메모리 사용량이 늘어나 결국 성능이 저하될 것임
스택이 커졌다가 줄어들었을 때 스택에서 꺼내진 객체들을 가비지 컬렉터가 회수하지 않음
스택이 그 객체들의 다 쓴 참조(obsolete reference)를 여전히 가지고 있기 때문임

해법

pop() 메서드 부분을 해당 참조를 다 썼을 때 null 처리(참조 해제) 하면된다.

public Object pop(){
    if(size == 0)
        throw new EmptyStackException();

    Object result = elements[--size];
    elements[size] = null;

    return result;
}

만약 null 처리한 참조를 실수로 사용하려 하면 프로그램은 즉시 NullPointerException을 던지면 종료

객체 참조를 null 처리하는 일은 예외적인 경우여야 한다.

자기 메모리를 직접 관리하는 클래스라면 프로그래머는 항시 메모리 누수를 주의해야 함

2. 캐시

캐시 역시 메모리 누수를 일으키는 주범이다.
캐시 외부에서 키를 참조하는 동안만 엔트리가 살아 있는 캐시가 필요한 상황이라면 WeakHashMap을 사용해 캐시를 만들자

3. 리스너 혹은 콜백

클라이언트가 콜백을 등록만 하고 명확히 해지하지 않는다면, 뭔가 조치해주지 않는 한 콜백을 계속 쌓여갈 것임
콜백을 약한 참조(weak reference)로 저장하면 가비지 컬렉터가 즉시 수거해감

정리

메모리 누스는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원해야만 발견되기도 함
그래서 이런 종류의 문제는 예방법을 익혀두는 것이 매우 중요