미로

모든 구체 클래스에서 Object의 toStgring을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString을  재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.

equals를 재정의 할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다.

재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다. 이렇게 구현하기가 어렵지는 않지만 조금 따분한 일이긴하다. 아이템 10에서 이야기한 AtuoValue 프레임워크를 사용하여 equals와 hashCode 를 자동으로 만들어준다. (IDE에서도 기능 일부 제공)

꼭 필요한 경우가 아니면 equals를 재정의하지 말자. 많은 경우에 Object의 equals가  여러분이 원하는 비교를 정확히 수행해준다. 재정의해야 할 때는 그 클래스의 핵심 필드 모두를 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다.

1. 반사성(reflexivity) - 객체는 자기 자신과 같아야한다. 

2. 대칭성(symmetry) - x.equals(y) 라면 y.equals(x) 도 true 여야한다. 

3. 추이성(transitivity) - 첫번째 객체와 두번째 객체가 같고, 두번째 객체와 세번째 객체가 같다면, 첫번째 객체와 세번째 객체도 같아야 한다.

4. 일관성(consistency) - 두 객체가 같다면(수정되지 않는 한)  앞으로 영원히 같아야한다. 

5. non-null(non-null) - 모든 객체가 null이 아니어야 한다.

꼭 회수해야 하는 자원을 다룰때는 try -finally 말고, try-with-resource 를 사용하자. 

예외는 없다. 코드는 더짧고 분명해지고, 만들어지는 예외정보도 훨씬 유용하다. try-finally로 작성하면 실용적이지 못하고 코드가 지저분해지는 경우라도, try-with-resources로는 정확하고 쉽게 자원을 회수할 수 있다.

cleaner(자바 8까지는 finalizer)는 안전망 역할이나 중요하지 않은 네이티브 자원 회수용으로만 사용하자.

물론 이런 경우라도 불확실성과 성능 저하에 주의해야 한다.

메모리 누수는 겉으로 잘 드러나지 않아 시스템에 수년간 잠복하는 사례도 있다. 이런 누수는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원해야만 발견되기도 한다. 그래서 이런 종류의 문제는 예방법을 익혀두는 것이 매우 중요하다.