개발서적읽기/Effective Java 3E
-
[이펙티브 자바] item 9 - try-finally보다는 try-with-resources를 사용하라개발서적읽기/Effective Java 3E 2020. 6. 29. 00:11
■자원 닫기의 중요성 InputStream, OutputStream, java.sql.Connection 등은 close 메소드를 호출해서 직접 닫아줘야 한다. 그런데 깜빡하고 자원을 닫지 않으면 예측할 수 없는 성능 문제로 이어질 수 있다. 이 상황을 방지하기 위해 finalizer를 활용할 수도 있지만 좋은 방법이 아니다. (item 8) 일반적으로 자원을 닫는 두가지 방법이 있다. 전통적인 방법인 try-fianlly와 java 7 이후 사용할 수 있는 try-with-resources이다. ■자원을 닫는 전통적인 방법 :: try-finallystatic String firstLineOfFile(String path) throws IOException { BufferedReader br = new..
-
[이펙티브 자바] item 8 - finalizer와 cleaner 사용을 피하라개발서적읽기/Effective Java 3E 2020. 6. 25. 12:48
■자바가 제공하는 객체 소멸자 2가지, finalizer와 cleaner@Override public void finalize() { // ... }Object 클래스에 정의된 finalize 메서드를 Override하면 해당 객체가 GC 대상이 될 때 finalize 메소드가 호출된다. 그런데 문득 궁금한 점이 생겼다. 메소드 이름은 finalize인데 책은 finalizer라고 표현한다. 무슨 차이가 있는걸까? 출처 에 따르면, GC가 어떤 객체를 memory 해제하려고 하는데 그 객체가 finalize 메소드를 재정의한 경우 즉각적으로 Collection(회수) 되지 않는다. 대신 Finalization Queue에 들어간 후 Finalizer에 의해 정리가 된다. Finalizer는 객체의 fin..
-
[이펙티브 자바] item 7 - 다 쓴 객체 참조를 해제하라개발서적읽기/Effective Java 3E 2020. 6. 23. 22:42
■GC가 메모리에서 회수하기 힘든 '다 쓴 참조' 객체 GC가 다 쓴 객체를 알아서 회수해간다고 해서 메모리 관리에 더 이상 신경쓰지 않아도 된다고 오해할 수 있는데, 절대 사실이 아니다. 아래 Stack을 사용하는 프로그램을 오래 실행하다 보면 점차 GC 활동과 메모리 사용량이 늘어나 결국 성능이 저하될 것이다. 상대적으로 드문 경우긴 하지만 심할 때는 디스크 페이징이나 OutOfMemoryError를 일으켜 프로그램이 예기치 않게 종료되기도 한다. 과연 메모리 누수가 일어나는 위치는 어디일까? public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACI..
-
[이펙티브 자바] item 6 - 불필요한 객체 생성을 피하라개발서적읽기/Effective Java 3E 2020. 6. 22. 21:15
■String 리터럴을 이용한 불필요 객체 생성 방지 - 불필요한 객체 생성String s = new String("bikini");이 문장은 실행될 때마다 String 인스턴스를 새로 만든다. 완전히 쓸떼없는 행위다. 생성자에 넘겨진 "bikini" 자체가 이 생성자로 만들어내려는 String과 기능적으로 완전히 똑같다. 아래는 문제점을 개선한 코드다.String s = "bikini";이 코드는 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용한다. 그리고 같은 가상 머신 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 사용함이 보장된다. (String constant pool in Heap) ■정적 팩터리 메서드를 이용한 불필요 객체 생성 방지 생성자 대신..
-
[이펙티브 자바] item 5 - 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라개발서적읽기/Effective Java 3E 2020. 6. 22. 00:38
public class SpellChecker { private static final Lexicon dictionary = ~~~; public static boolean isValid(String word){ ~~ } }위 정적 유틸리티 클래스(item 4)는 유연하지 않고 테스트하기 어렵다. 사전이 여러개일 가능성이 충분히 충분(?)한데, 위 코드는 다른 사전으로 스펠링을 체크하기 위해선 코드를 수정해야만 한다. 여러 자원 인스턴스를 지원하고, 클라이언트가 원하는 자원(dictionary)을 사용하게 할 수 있는 유연한 스펠링 체크 클래스로 수정해보자. ■방법 1 :: dictionary set 메소드 dictionary의 final 키워드를 제거하고 set 메소드를 추가하는 방법이다. 이 방식은 ..
-
[이펙티브 자바] item 4 - 인스턴스화를 막으려거든 private 생성자를 사용하라개발서적읽기/Effective Java 3E 2020. 6. 10. 01:50
■Static 메서드와 변수만을 담는 클래스는 정말 필요할 때만 사용하자 정적 메서드와 정적 필드만을 담는 클래스는 객체지향에 맞지 않기 때문에 지양하는 것이 좋다. 그러나 꼭 필요한 곳에서는 요긴하게 쓰일 수 있어, 잘 판단해서 사용하면 좋다. 아래와 같은 유틸리티성 클래스를 예로 들 수 있겠다. - java.lang.Math - java.lang.Arrays - java.lang.Collectionsfinal 클래스와 관련한 메서드들을 모아놓을 때도 사용한다. 특정 라이브러리를 사용중이고, 그 라이브러리 내의 클래스에 어떤 메소드를 추가하고 싶을 수가 있다. 이러한 경우엔 그 클래스를 상속한 후 원하는 메소드를 추가하면 된다. 그런데 하필 그 클래스가 final 클래스라면? 상속은 불가능하다. 그럴땐..
-
[이펙티브 자바] item 3 - private 생성자나 열거 타입으로 싱글턴임을 보증하라개발서적읽기/Effective Java 3E 2020. 6. 1. 21:51
싱글톤 자세히 ■싱글톤 클래스 설계 시, 주의할 점 :: 테스트 클래스를 싱글톤으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려울 수 있음 싱글톤 인스턴스를 가짜(mock) 구현으로 대체할 수 없기 때문 (타입을 인터페이스로 정의한 다음 그 인터페이스를 구현해서 만든 싱글톤이 아니라면) ■싱글톤 클래스 설계 :: private 생성자public class UserDao { private static UserDao INSTANCE; private UserDao(ConnectionMaker connectionMaker) { if(INSTANCE != null){ throw new IllegalStateException(); } this.connectionMaker = connectionMaker; }..
-
[이펙티브 자바] item 2 - 생성자에 매개변수가 많다면 빌더를 고려하라개발서적읽기/Effective Java 3E 2020. 5. 19. 21:23
■상황 어떤 클래스의 인스턴스를 반환해야 하는 상황이 생겼다. 생성자나 정적 팩토리 메서드를 만들면 될 것 같다. 그런데 생성자나 정적 팩터리 메서드에 필요한 선택적 매개변수가 많은 경우는 어떻게 할까? ■첫 번째 방법 : 점층적 생성자 패턴 가장 심플한 방법이다. 생성자나 팩터리 메서드를 오버로딩하면 된다. 하지만 이 방법은 코드가 더러워지는(?) 특징을 가지고 있다.public class NutritionFacts { private final int servingSize; // (mL, 1회 제공량) 필수 private final int servings; // (회, 총 n회 제공량) 필수 private final int calories; // (1회 제공량당) 선택 private final int ..