백엔드 개발자 블로그

equals를 재정의시 hashCode도 재정의 해야하는 이유 Ojbect 명세서에는 다음과 같은 규약이 있습니다. eauals 비교에 사용되는 정보가 변경되지 않는다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다. 여기서 두번째에 위치한 조항을 ..

java의 Object들에 재정의를 하는 equals의 경우 잘못 사용하면 끔찍한 결과를 초래할 수 있습니다. 그래서 equals는 객체의 논리적 동치성을 확인해야할 때 빼고 불필요한 경우에는 재정의를 하지 않는 것이 더 좋습니다. equals를 재정의하지 않아도 되는 상황 각 인스턴스가 본질적으로 고유한 경우 인스턴스의 논리적 동치성(logical equality)를 검사할 일이 없는 경우 상위 클래스에서 재정의한 equals가 하위 클래스에도 맞는 경우 클래스가 private, package-private이고 equals메서드를 호출할 일이 없는 경우 equals를 호출될 일이 전혀 없는 경우 다음과 같이 막을 수도 있다. @Override public boolean equals(Object o) {..

상황 InputStream, OutPutStream, java.sql.Connection과 같은 자원들은 사용 후에 close()메서드를 통해 자원을 회수 해줘야 합니다. 예측하기 어려운 성능 문제로 이어지기도 하기에 곡 close()를 해줘야 됩닌다. try-finally 문제점 try문과 finally 내에서 모두 예외가 발생하는 경우 디버깅이 어렵습니다. 코드가 지저분합니다. finally {br.close();} 코드를 작성할 작성 해줘야 됩니다. 1번 문제 해결을 위해 예외 설정 코드를 추가하게 되면 코드가 지저분해집니다. static String firstLiseOfFile(String path) throws IOException { BufferedReader reader = new Buffe..

자바에서는 사용하지 않는 객체의 경우 GC(Garbage Collection)에서 알아서 회수를 해주며 메모리 관리를 해줍니다. 하지가비지 컬렉션에서는 특정 상황에서 메모리 누수가 발생하고, 우리는 그러한 상황을 인지하고 대응해줘야합니다. 메모리 누수는 언제 발생할까? 다 쓴 객체 참조(obsolete reference)를 해제하지 않고 갖고 있을 경우 메모리 누수가 발생합니다. public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_CAPACITY]; } public..