| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- UNICON
- Route53
- 42서울
- 캡스톤디자인프로젝트
- 도커
- Spring boot
- 생활코딩
- 프롬프트엔지니어링
- 개발공부
- 스프링부트
- spring ai
- 프리티어
- EC2
- 오블완
- UNIDEV
- NAT gateway
- 전국대학생게임개발동아리연합회
- 티스토리챌린지
- 체크인미팅
- openAI API
- 인프라
- 백엔드개발자
- Redis
- 프로그래밍
- UNICON2023
- bastion host
- CICD
- AWS
- 라피신
- 게임개발동아리
- Today
- Total
Hyun's Wonderwall
[Java] 이펙티브 자바 - 11장(2/2), 12장(1/2) (아이템 82-) 본문
11장: 동시성
아이템 82. 스레드 안전성 수준을 문서화하라
'한 메서드를 여러 스레드가 동시에 호출할 때 그 메서드가 어떻게 동작하느냐': 해당 클래스의 클라이언트에게 중요한 정보. 가정해서 사용했다가 틀리면 심각한 오류로 이어짐.
모든 클래스가 자신의 스레드 안전성 정보를 명확히 문서화해야 한다.
synchronized 한정자는 문서화와 관련X ( 'API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다?' -> X. javadoc이 기본 옵션에서 생성한 API문서에는 synchronized 한정자가 포함되지 않는다. 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않아, 따라서 이것만으로 메서드가 스레드 안전하다고 믿기 어렵다.)
멀티스레드 환경에서도 API를 안전하게 사용하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다.
<스레드 안전성 높은 순으로 나열한 것>
1. 불변
2. 무조건적 스레드 안전 (내부에서 충실히 동기화함. 이 클래스를 작성할 때는 synchronized 메서드가 아닌 비공개 락 객체를 사용하자. 이렇게 해야 클라이언트나 하위 클래스에서 동기화 메커니즘을 깨뜨리는 걸 예방할 수 있고, 필요하다면 다음에 더 정교한 동시성을 제어 메커니즘으로 재구현할 수 있다.)
3. 조건부 스레드 안전 (일부 메서드는 동시에 사용하려면 외부 동기화가 필요. 메서드를 어떤 순서로 호출할 때 외부 동기화가 요구되고, 그때 어떤 락을 얻어야 하는지도 알려줘야 한다.)
4. 스레드 안전하지 않음 (내부 인스턴스 수정될 수 있어, 동시에 사용하려면 클라가 외부 동기화 매커니즘으로 감싸야)
5. 스레드 적대적 (외부 동기화로 감싸도 멀티스레드 환경에서 안전하지 않음)
아이템 83. 지연 초기화는 신중히 사용하라
지연 초기화: 필드의 초기화 시점을 그 갑싱 처음 필요할 때까지 늦추는 기법.
But. 대부분의 상황에서 일반적인 초기화가 지연 초기화보다 낫다. 지연시키지 말고 곧바로 초기화 추천.
성능 때문에 혹은 위험한 초기화 순환을 막기 위해 꼭 지연 초기화를 써야 한다면 올바른 지연 초기화 기법을 사용하자.
- 인스턴스 필드에는, 이중검사 관용구 사용
- 정적 필드에는, 지연 초기화 홀더 클래스 관용구 사용
반복해 초기화해도 괜찮은 인스턴스 필드에는 단일검사 관용구도 고려 대상이다.
아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라
프로그램의 정확성/성능이나 동작을 스레드 스케줄러에 기대면 견고성, 이식성이 떨어진다.
Thread.yield와 스레드 우선순위에 의존해서도 안 된다.
12장: 직렬화
아이템 85. 자바 직렬화의 대안을 찾으라
직렬화는 위험하니 피해야 한다.
JSON, 프로토콜 버퍼 같은 대안을 사용하자.
객체 역직렬화 필터링.
되도록 클래스가 직렬화를 지원하도록 만들지 마라.
아이템 86. Serializable을 구현할지는 신중히 결정하라
Serializable은 구현한다고 선언하기는 쉽지만, 구현하면 릴리스한 뒤 수정하기 어렵다. 만약 꼭 필요해서 한다면 아주 신중하게 이뤄져야 한다.
아이템 87. 커스텀 직렬화 형태를 고려해보라
객체를 적절히 설명하는 커스텀 직렬화를 고안하라.
직렬화 형태에 포함된 필드 마음대로 제거할 수 없으니 주의.
아이템 88. readObject 메서드는 방어적으로 작성하라
readObject 메서드를 작성할 때 언제나 public 생성자를 작성하듯 해야한다.
안전한 readObject 메서드 작성 지침
1. private이어야 하는 객체 참조 필드는 각 필드가 가리키는 객체를 방어적으로 복사하라. 불변 클래스 내의 가변 요소가 여기 속한다.
2. 모든 불변식을 검사하여 어긋나는 게 발견되면 InvalidObjectException을 던진다. 방어적 복사 다음에는 반드시 불변식 검사가 뒤따라야 한다.
3. 역직렬화 후 객체 그래프 전체의 유효성을 검사해야 한다면 ObjectInputValidation 인터페이스를 사용하라.
4. 직접적이든 간접적이든, 재정의할 수 있는 메서드는 호출하지 말자.
아이템 89. 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
readResolve를 인스턴스 통제 목적으로 사용한다면 객체 참조 타입 인스턴스 필드를 모두 transient로 선언해야 한다. 그러니 가능한 한 열거 타입을 사용하자.
아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라
제3자가 확장할 수 없는 클래스라면 가능한 한 직렬화 프록시 패턴을 사용하자. 이것이 불변식을 안정적으로 직렬화해주는 가장 쉬운 방법.
'Study > Java' 카테고리의 다른 글
| [Java] 이펙티브 자바 - 9장(2/2), 10장(1/2) (아이템 64-72) (0) | 2025.09.06 |
|---|---|
| [Java] 이펙티브 자바 - 8장(2/2), 9장(1/2) (아이템 55-63) (1) | 2025.08.30 |
| [Java] 이펙티브 자바 - 7장(2/2), 8장(1/2) (아이템 46~54) (0) | 2025.08.23 |
| [Java] 이펙티브 자바 - 6장(2/2), 7장(1/2) (아이템 37~45) (2) | 2025.08.16 |
| [Java] 이펙티브 자바 - 5장(2/2), 6장(1/2) (아이템 28~36) (4) | 2025.08.16 |