아이템 69. 예외는 진짜 예외 상황에만 사용하라. 예외는 진짜 예외 상황에서만 사용해야함. 예외를 잘못 사용한 예시 흐름제어에 예외를 사용함 → 흐름제어에 사용된 예외 때문에 진짜 예외가 무시되어 디버깅이 어려워 질 수 있음. 예외 대신 흐름제어에 사용할만한 것 Optional 상태 검사 메서드 특정 값 중 하나 선택 선택 기준 Optional이나 특정값 사용 상태 검사 메서드 - 상태 메서드 사이에 동시성 문제가 있을 수 있는 경우 성능이 중요한데, 상태 검사 메서드 / 상태 메서드가 중복된 작업이 일부 있는 경우 나머지 경우 상태 검사 메서드 사용하는 것이 유리. 예외를 잘못 사용한 경우. 아래 코드는 무엇을 의미하는 것일까? 단순히 코드만 봤을 때는 무엇을 하는지 전혀 알 수 없다. // 아래 코..
Method 10 100 1000 1,000,000 10,000,000 100,000,000 simpleFunctionWithoutLock 1ms 1ms 2ms 37ms 1.6s 20.9s simpleFunctionWithLock 0ms 0ms 1ms 20ms 0.7s 21.3s simpleFunctionWithLockSleep 106ms 1040ms 109700ms - - - Method 10 100 1,000 10,000 100,000 1,000,000 10,000,000 100,000,000 putWithoutLock 1ms 1ms 3ms 9ms 34ms 217ms 2085ms 23558ms putWithLock 1ms 1ms 2ms 7ms 28ms 172ms 920ms 20060ms Method ..
아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라. 체크 예외 : 복구할 수 있는 상황일 때 던져라. 언체크 예외 : 복구할 수 없는 상황일 때 던져라. 언체크 예외를 구현할 때는 반드시 RuntimeException 클래스를 상속해서 만들어라. 복구 가능한 상황인지 잘 모르겠으면, 언체크 예외를 던져라 필요하다면 예외 클래스에 도우미 메서드를 추가해서 복구를 손쉽게 할 수 있도록 하는게 좋을 수 있음. 몇 초 후에 재시도 해야한다는 메세지가 있다면, 그 메세지를 예외에 넣는다. 그리고 사용자에서 이 값을 간단히 get() 메서드를 이용해서 사용해 볼 수도 있다. 체크 예외 vs 언체크 예외 자바에서는 크게 두 가지 타입의 예외가 존재한다. 체크 예외 : 예..
아이템 71. 필요없는 체크 예외 사용은 피하라 체크 예외는 복구 가능한 상황을 알려서 이 API를 사용하는 개발자가 복구를 시도하도록 강제함. 복구 불가능한 예외라면 비검사 예외를 던져서 사용하기 편리한 API를 제공 해야 함. 복구 가능한지 명확하지 않다면 비검사 예외를 던져라. 검사 예외가 추가되면 다음 문제가 발생함. try ~ catch를 사용해야 함. Stream에서 사용할 수 없음. 검사 예외를 회피하는 방법 Optional 반환하기 → 단점은 예외 정보가 없음. 검사 예외를 던지는 메서드를 2개로 쪼개서, 상태 검사로 분기 처리하기 → 멀티 쓰레드 환경에서 상태검사 동기화가 필요함. 체크 예외를 던지면 사용하기 어려운 API가 됨. 메서드에서 체크 예외를 던지면, 이 메서드를 사용하는 클라..
쓰레드 모델 아래같은 쓰레드 모델이 존재한다. 여기서 자바는 (b) Pure kernel-level 쓰레드 모델을 사용하고 있다. JDK의 구현마다 다르겠지만, 내가 테스트 해본 OpenJDK 17, 21에서 쓰레드풀 사이즈가 증가하는만큼 OS 쓰레드 개수가 증가하기 때문에 유절 레벨 쓰레드 - 커널 레벨 쓰레드는 One To One으로 Binding 된다고 이해했다. 쓰레드는 스케쥴링을 관리하는 주체가 유저 / 커널이냐에 따라 유저 레벨 쓰레드와 커널 레벨 쓰레드가 존재한다. 위의 쓰레드 모델을 살펴보면 다음과 같다. (a) Pure user-level : 커널은 프로세스가 CPU를 사용할 수 있도록 스케쥴링 해줌. 프로세스 내부의 유저 레벨 쓰레드의 스케쥴링은 프로세스 라이브러리에서 처리함. 프로세스..