The Nirsa Way

equals는 일반 규약을 지켜 재정의하라 - equals의 일반 규약 알아보기Object 명세에 작성된 내용을 확인해보면 equals 메서드는 널이아닌 객체들에 대해 동치 관계(equivalence relation)을 만족해야 하며 아래의 조건들을 지켜야 한다는 내용이 있습니다. 아래와 같이 크게 5가지로 이루어집니다.반사성(Reflexivity)대칭성(Symmetry)추이성(Transitivity)일관성(Consistency)non-null5가지 규약들에 대하여 설명을 보면 은근히 헷갈리게 써있지만 예시 코드를 확인해 보시면 당연하다면 당연한 이야기들이라 이해하기 어렵지 않을 것 입니다. 이제 각 항목들에 대한 예시 코드를 작성해가며 확인해볼텐데, 예시 코드는 이전 포스팅인 [Effective Jav..

equals는 일반 규약을 지켜 재정의하라 - equals를 재정의해야 하는 상황과 인스턴스 통제 클래스주로 Value Object들이 equals()를 재정의할 상황을 가집니다. Object의 equals()는 기본적으로 참조 동일성 비교(==)를 사용하게 되는데 값을 주로 저장하는 Value Object의 경우 논리적 동치성(값이 동일한가)을 검사할 상황이 발생합니다. 즉 "같은 값을 가지고 있는가?"를 판단해야 한다면 equals()를 재정의할 필요가 있을 것 입니다.아래의 코드는 금액(amount)과 통화(currency) 값을 저장하는 Value Object 입니다. equals()를 재정의하여 값이 일치하는지 비교하는 로직이 추가된 상태입니다.public class Money { priv..

equals는 일반 규약을 지켜 재정의하라 - equals를 재정의하지 않아야 할 4가지 상황 일반적으로 equals는 아래의 상황 중 하나에 해당한다면 재정의 하지 않는 것이 좋습니다.각 인스턴스가 본질적으로 고유하다.인스턴스의 논리적 동치성(logical quality)을 검사할 일이 없다.상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다.클래스가 private 이거나 pacakge-private이고 equals를 호출할 일이 없다. 1. 각 인스턴스가 본질적으로 고유하다.값을 표현하는 클래스가 아니라 동작을 수행하는 개체일 경우 equals의 재정의하지 않는 것이 적절합니다. 예를 들어 Thread, Excutor, Rannable, Connection, Stream 같은 객체..

try-finally 보다는 try-with-resources를 사용하라try-finally의 경우 인스턴스를 명시적으로 close()를 호출하여 닫아주어야 합니다. 만약 개발자의 실수로 자원을 제대로 닫지 않는다면 성능의 문제가 발생할 가능성이 있으며 try와 finally 모두 예외가 발생된다면 try에서 발생한 예외가 덮어씌워질 수 있습니다.file.txt의 첫번째 줄을 읽은 후 출력하는 코드를 try-finally를 사용하여 구현한다고 하면 아래와 같이 될겁니다.finally를 주의 깊게 본다면 reader가 null이 아닌지 체크(NPE 방지)를 하고 close()를 수행합니다. 하지만 close() 수행 중 IOException이 발생할 가능성이 있으므로 또 다시 try-catch를 사용하여..

finalizer와 cleaner 사용을 피하라객체 소멸자 finalizer와 cleaner는 GC에 의해 실행되며 실행 시점 보장이 없기에 예측되지 않습니다. 즉 GC의 알고리즘에 따라 천차만별이며 테스트 과정의 JVM에서는 잘 동작 했지만 배포된 서버에서는 정상적인 동작을 하지 않아 문제가 발생할 수 있습니다.아래의 코드는 finalize()의 예시 코드이며 객체 생성한 다음 참조 해제하여 gc를 요청하는 코드입니다. 즉 gc는 obj 객체의 참조가 비워져 있으므로 메모리를 수거하려고 할 것 입니다. 또한 finalize()를 오버라이딩 했음으로 GC가 해당 객체를 수거할 때 finalize() 메서드가 호출됩니다.public class Test { @Override protected vo..

다 쓴 객체 참조를 해제하라메모리 누수(Member Leak)을 방지하기 위해 다 쓴 객체는 참조를 해제하라는 말 뜻입니다. 일반적으로 자바에서는 GC(Garbage Collector)가 객체를 회수하지만 GC의 특성상 "해당 객체를 참조하는 곳이 없어야 수거" 합니다.즉, 더 이상 객체를 사용하지 않지만 어디선가 참조되고 있다면 GC는 해당 객체를 수거하지 않으며 메모리 누수가 발생하는 경우가 생길 수 있습니다. 예시는 아래와 같은 코드입니다.public class Stack { private Object[] elements; private int size = 0; public Stack() { elements = new Object[10]; } public v..

오토박싱(auto-boxing)과 언박싱(unboxing)자바는 기본형(int, long, double, ...)과 래퍼 클래스(Integer, Long, Double, ...)를 구분합니다. 기본형과 래퍼 클래스는 오토박싱과 언박싱을 통해 자동으로 이루어지지만 때로는 성능 저하로 이루어질 수 있습니다.우선 아래의 코드는 int 타입(10)을 Integer로 자동으로 변환시켜주는 오토 박싱의 예시입니다. 자바에서 숫자는 기본적으로 int 이므로 숫자 10은 기본형, 데이터 타입은 Integer인 래퍼클래스 이기에 자동으로 변환 시켜줍니다.Integer num = 10; 언박싱은 반대로 래퍼 클래스를 기본형으로 자동 변환해주는 것을 뜻하는데, 언박싱에 대한 내용은 포스팅 하단에 남기겠습니다. 오토 박싱의..

정규표현식 처리 성능 개선Java에서 문자열 정규식 검증을 위해 흔히 String.matches()를 사용합니다. 하지만 matches()는 내부적으로 Pattern 객체를 호출마다 새로 생성합니다. 즉, 한번 쓰고 버려져서 가비지 컬렉션 대상이 되는 객체가 매번 생성되는 것 입니다. 1회성이면 차이는 없지만 루프 또는 대량 처리에서 사용하면 심각한 성능 저하를 가져올 수 있습니다.public static void main(String[] args) { List inputs = Arrays.asList( "1234", "abc", "9876", "12a4", "0000", "42", "99999" ); // String.matches() - 매번 Pattern 객체 생성 ..

※ 정적 팩터리 메서드란 : https://nirsa.tistory.com/428 생성자 대신 정적 팩터리 메서드를 활용하라Java9 부터는 Boolean(String) 생성자를 사용하면 deprecated(사용 자제, 향후 제거 예정) 되어있는 것을 확인할 수 있는데 항상 새 인스턴스를 반환하므로 비효율적이고, 문자열이 true 외의 값이면 모두 false를 반환하는데 직관적이지 않은 이유가 있습니다.※ Boolean(String) 생성자는 deprecated 되었지만 예전부터 존재했기에 호환성에 대한 문제와 valueOf(String)으로 바꾸게 되면 내부에서 TRUE / FALSE를 참조할 때 순환 참조 이슈가 발생할 가능성 등이 많아 현실적으로 제거 되기엔 힘들지 않을까 싶습니다. 불필요한 객체 ..

불필요한 객체 생성을 피하라이미 생성된 객체를 재사용할 수 있다면 새로운 객체를 만들지 말고 기존에 사용중인 객체를 재사용하자라는 의미로써 객체 생성에 의한 비용을 줄여 GC 및 메모리 낭비를 줄이기 위함입니다. 아래와 같은 코드가 있다면 new String()에 의해 코드가 실행될 때 마다 매번 새로운 객체를 heap에 생성합니다. 같은 값을 가지고 있으므로 기존 객체를 재사용하면 되지만, 매번 새로운 객체를 만들기 때문에 매우 비효율적으로 동작하게 됩니다.System.out.println(new String("hello")); // 새 객체 생성 1System.out.println(new String("hello")); // 새 객체 생성 2// 또는 String str = new String("he..