반갑습니다!

equals 를 재정의한 클래스 모두에서 hashCode 도 재정의해야 함 그렇지 않으면 hashCode 일반 규약을 어기게 되어 HashMap 이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 생김 equals 비교에 사용되는 정보가 변경되지 않았다면, 어플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야함. 단, 어플리케이션을 다시 실행한다면 이 값은 달라져도 상관없음. equals(Object)가 두 객체를 같다고 판단햇다면, 두 객체의 hashCode는 똑같은 값을 반환해야함 equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없음. 단, 다른 객체에 대해서..

equals 메서드는 재정의하기 쉬워 보이지만 잘못하면 자칫하면 끔찍한 결과를 초래하므로 특정 상황에 해당한다면 재정의하지 않는 것이 최선 재정의하면 안되는 상황 각 인스턴스가 본질적으로 고유할 때 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스일 때 ex) Thread 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없을 때 java.util.regex.Pattern 은 equals 를 재정의해서 두 Pattern 의 인스턴스가 같은 정규표현식을 나타내는지(논리적 동치성)를 검사 할 수 있음 설계자가 클라이언트에서 이 방식을 원하지 않거나 필요하지 않다고 판단하면 재정의하지 않는 것이 좋음 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞..

Java 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많음 ex) InputStream , OutputStream , java.sql.Connection 이런 자원 중 상당수가 안전망으로 finalize 를 활용하고 있지만 그리 믿을만하지 않음(아이템 8) 전통적인 방법 전통적으로 자원을 제대로 닫힘을 보장하기 위해 try-finally가 쓰임 static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } 나쁘지 않은 방법..

Java는 두 가지 객체 소멸자를 제공 그 중 finalizer 는 예측할 수 없고, 상황에 따라 위험할 수 있어서 일반적으로 불필요함 오동작, 낮은 성능, 이식성 문제의 원인이 되기도 함 Java 9에서는 finalizer 를 deprecated하고 cleaner 를 대안으로 소개함 cleaner 는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요함 주의 Java의 finalizer 와 cleaner 는 C++의 파괴자(destructor)와는 다른 개념 C++에서 파괴자는 특정 객체와 관련된 자원을 회수하는 보편적인 방법 Java에서는 접근할 수 없게 된 객체를 가비지 컬렉터가 알아서 회수함 C++의 파괴자는 비메모리 자원을 회수하는 용도로 사용 Java에서는 try-with-re..

Java처럼 가비지 컬렉터를 갖춘 언어를 사용하다보면 자칫 메모리 관리에 신경 쓰지 않아도 된다고 오해할 수 있음 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();..