Study/이펙티브 자바

[Effective Java] 스레드 안전성 수준을 문서화하라

💥 개요한 메서드를 여러 스레드가 동시에 호출할 때 그 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다. 아무 언급도 없으면 가정을 해야하고, 그 가정이 틀리면 동기화를 충분히 못하거나 지나치게한 상태일 것이며, 두 가지 심각한 오류로 이어질 수 있다. ⚠️ 자바독 기본 옵션 생성 API 문서는 synchronized가 포함되지 않는다.메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않는다.멀티 스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다. 일반적인 경우 스레드 안전성이 높은 순서는 아래와 같다.불변(immutable) : 이 클래스의 인스턴스는 마..

2024. 5. 20. 21:11

Study/이펙티브 자바

[Effective Java] 과도한 동기화는 피하라

💥 개요과도한 동기화는 성능을 떨어뜨리고, 교착상태에 빠뜨리고 심지어 예측할 수 없는 동작을 낳기도 한다.응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대 클라이언트에 양도하면 안 된다.아래는 동기화 영역 안에서 해서 안되는 예시이다.재정의할 수 있는 메서드 호출클라이언트가 넘겨준 함수 객체 호출 ⚠️ 구체적인 예시// Broken - invokes alien method from synchronized block!public class ObservableSet extends ForwardingSet { public ObservableSet(Set set) { super(set); } private final List> observers ..

2024. 5. 13. 21:51

Study/이펙티브 자바

[Effective Java] 메서드가 던지는 모든 예외를 문서화하라

💥 개요메서드가 던지는 예외는 그 메서드를 올바로 사용하는 데 아주 중요한 정보다. 따라서 문서화에 충분히 신경써야 한다.검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용해 정확히 문서화해야 한다. 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자. 극단적인 예로 메서드가 Exception이나 Throwable을 던진다고 선언해서는 안 된다. 힌트도 주지 못하고 다른 예외까지 삼켜버릴 수 있어 API 사용성을 크게 떨어뜨린다.(main 메서드 제외함. JVM만이 호출하므로 괜찮다.) 🕹️ 비검사 에외도 문서화하자자바 언어가 요구하는 것은 아니지만 비검사 예외도 정성껏 문서화하면 좋다. 일반적으로 프로그래밍 오류를 비검사 예외라고 말하는데, 자신이..

2024. 5. 8. 21:55

Study/이펙티브 자바

[Effective Java] 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

💥 개요호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.이것이 검사와 비검사 예외를 구분하는 기본 규칙이다.검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려준다.즉, API 설계자는 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한것이다. 💡 비검사 throwable 2가지런타임 예외와 에러는 둘 다 동작 측면에서는 다르지 않다. 이 둘은 잡을 필요가 없거나 혹은 잡지 말아야 한다.프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다 실이 많다는 뜻이..

2024. 5. 7. 21:25

Study/이펙티브 자바

[Effective Java] 예외는 진짜 예외 상황에만 사용하라

💥 개요try { int i = 0; while(true) { ranmge[i++].climb();} catch(ArrayIndexOutOfBodundsException e) {}위와 같은 코드는 전혀 직관적이지 않다. 배열의 원소를 순회하는데, 아주 끔찍한 방식으로 사용하고 있다. 무한루프를 돌다가 배열의 끝에 도달해  ArrayIndexOutOfBodundsException이 발생하면 끝을 내는 것이다.이 코드의 의도는 잘못된 추론을 근거로 성능을 높이려 했다. JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료한다. 따라서 이 검사를 반복문에도 명시하면 같은 일이 중복되므로 하나를 생략한 것이다.하지만 3가지 문제가 있..

2024. 5. 6. 20:12

Study/이펙티브 자바

[Effective Java] 객체는 인터페이스를 사용해 참조하라

💥 개요 "매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라"는 말을 이전 챕터에서 한 적이 있다. 이는 "객체는 클래스가 아닌 인터페이스로 참조하라"는 말로 확장이 가능한데, 적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언해야한다. 객체의 실제 클래스를 사용해야 할 상황은 생성자로 생성할 때 뿐이다. //좋은 예시. 인터페이스를 타입으로 선언 Set sonSet = new LinkedHashSet(); //나쁜 예시. 클래스를 타입으로 사용 LinkedHashSet sonSet = new LinkedHashSet(); 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해질 것이다. 나중에 구현 클래스를 교체하고자 한다면 그저 새 클..

2024. 4. 22. 22:00