💻/Java

아이템 8 finalizer와 cleaner 사용을 피하라 Java 2가지 객체 소멸자: finalizer, cleaner-> 예측 불가능, 성능 저하, 동시성 문제 유발finalizer: Java 9 deprecated API로 지정, 위험성 ↑cleaner: `finalizer`보다 덜 위험 But, 여전히 느리고, 불필요, 예측 X!= C++의 파괴자(destructor)(생성자 대척점) 객체 소멸될 때 그와 연결된 자원(메모리 + 비메모리) 자동 회수vs Java: GC) 접근할 수 없게 된 객체 회수(메모리만 관리)-> 비메모리 자원은 `try-with-resources`와 `try-finally` 사용해 해결finalizer와 cleaner 피해야 하는 이유1) 실행 시점 보장 XGC가 객체 ..

아이템 7 다 쓴 객체 참조를 해제하라C,C++: 메모리 직접 관리 / Java: GC가 더 이상 사용 X 객체 회수-> 메모리 관리에 신경 쓰지 않아도 된다고 오해 메모리 누수 예시: 스택 구현public class Stack { private Ojbect[] 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[s..

아이템 6 불필요한 객체 생성 피하라 똑같은 기능의 객체 매번 생성 -> 빠르고 세련됨/ 특히, 불변 객체는 언제든 재사용 O 불필요한 객체 생성 예시1) 하지 말아야 할 극단적인 예String s = new String("asdf");`new String("asdf")`: 실행될 때마다 새로운 `String` 인스턴스 생성생성자에 넘겨진 `asdf` 자체가 이미 동일한 `String` 객체 반복문 or 빈번히 호출되는 메서드에서 사용 -> 수백만 개의 불필요한 객체 생길 수 O 개선 버전String s = "asdf";새로운 인스턴스 매번 만드는 대신 하나의 `String` 리터럴 재사용JVM) 동일한 문자열 리터럴 사용하는 모든 코드가 같은 객체 공유하도록 보장 2) 정적 팩터리 메서드 사용생성자) ..

아이템 5 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라클래스가 하나 이상의 자원에 의존ex. 맞춤법 검사기(SpellChecker) -> 사전(Lexicon)에 의존정적 유틸리티 클래스 or 싱글턴으로 자원 직접 지정 -> 유연성 ↓, 테스트 어려움잘못된 접근1) 정적 유틸리티사전 교체 X -> 다국어, 테스트용 Mock 어려움public class SpellChecker { private static final Lexicon dictionary = ...; private SpellChecker() {} // 객체 생성 방지 public static boolean isValid(String word) {...} pbulic static List suggestions..

아이템 3 private 생성자나 열거 타입으로 싱글턴임을 보증하라싱글턴(singleton)인스턴스를 오직 하나만 생성할 수 있는 클래스적용 대상: 무상태(stateless) 객체 or 설계상 유일해야 하는 시스템 컴포넌트(-) 테스트 어려움인터페이스 기반 설계 X -> Mock 대체 X싱글턴 구현 방식1) `public static final` 필드 방식public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() {...} public void leaveTheBuilding() {...}}클래스 초기화 시점에 인스턴스 한 번 생성API에 싱글턴임이 명확히 드러남리플랙션(`AccessibleO..