아이템 85. 자바 직렬화의 대안을 찾으라 - 아주 신중하게 제작한 바이트 스트림만 역직렬화 해야- 직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화 하지 않는 것- 새로운 시스템에서 자바 직렬화를 써야하는 경우는 전혀 없음- 신뢰할 수 없는 데이터는 절대 역직렬화 하지 않아야- 직렬화를 피할 수 없고 역직렬화한 데이터가 안전한 지 완전히 확신할 수 없다면 객체 역직렬화 필터링을 사용 아이템 86. Serializable을 구현할지는 신중히 결정하라 - Serizalizable을 구현하면 릴리스한 뒤에는 수정하기 어려움 - private 인스턴스 마저 api로 공개되는 꼴(캡슐화가 깨짐) - 버그와 보안 구명이 생길 수 있음 - 역직렬화는 숨은 생성자임 - 기본 역직렬화를 사용하면 불변식 꺠짐과..

아이템 78. 공유 중인 가변 데이터는 동기화해 사용하라 - synchronizaed 는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장 - 상태가 일관되지 않은 순간의 객체가 다른 스레드가 보지 못하게 막는 용도로만 생각 - 동기화는 배타적 실행 뿐 아니라 스레드 사이의 안정적인 통신에 꼭 필요 - volatile 선언하면 동기화를 생략해도 됨 - 배타적 수행과는 상관 없지만 항상 가장 최근에 기록된 값을 보장 - 메서드에 synchronized를 붙였으면 volatile 제거해야 - Atomic 패키지는 락 없이도 스레드 안전한 프로그래밍을 지원 - Atomic 은 원자성(배타적 실행)까지 지원 - 가장 좋은 방법은 애초에 가변 데이터를 공유하지 않는 것 - 가변데이터는 단일 스레드에서만 사..

아이템 69. 예외는 진짜 예외 상황에만 사용하라 - 예외는 오직 예외 상황에서만 써야 한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다 - 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 # 상태 검사 메서드, 옵셔널, 특정 값 중 하나를 선택하는 지침 1. 외부 동기화 없이 여러 스레드가 동시에 접근 가능하거나 외부 요인으로 상태가 변할 수 있다면 옵셔널이나 특정 값 사용 2. 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값 선택 3. 다른 모든 경우엔 상태 검사 메서드 방식이 더 나음 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 - 호출하는..

아이템 57. 지역변수의 범위를 최소화하라 - 지역변수의 범위를 줄이는 가장 강력한 기법은 역시 가장 처음 쓰일 떄 선언하기- 거의 모든 지역변수는 선언과 동시에 초기화해야(try-catch 제외)- 반복문이 종료된 뒤에도 써야 하는 상황이 아니라면 while문보다 for 쓰기 아이템 58. 전통적인 for 문보다는 for-each 문을 사용하라 ## for-each 못쓰는 상황 - 파괴적인 필터링 : 선택된 원소를 제거해야 한다면 사용 불가 - 변형 : 원소의 값 일부 혹은 전체 교체시 사용 불가 - 병렬 반복 : 병렬 순회시 사용 불가 아이템 59. 라이브러리를 익히고 사용하라 # Random 사용 시 문제점 - 나머지 연산값이 2의 제곱수라면 같은 수열이 반복 - 나머지 연산값이 2의 제곱수가 아니..

아이템 49. 매개변수가 유효한지 검사하라 - 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 - 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 - 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때는 검사 패스해도 됨 아이템 50. 적시에 방어적 복사본을 만들라 - 클라이언트가 여러분의 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 - 생성자에서 받은 가변 매개변수를 각각 방어적으로 복사해야 - 매개변수가 제 3자에 의해 확장될 수 있는 타입이라면 방어적 복사본을 만들 때 clone 사용해서는 안 됨 - 인스턴스를 복사하는 데는 일반적으로 생성자나 정적 팩터리를 쓰는 것이 좋음 - 그 객체가 잠재적으로..

아이템 42. 익명 클래스보다는 람다를 사용하라 - 타입을 명시해야 코드가 더 명확할 때만 제외하고는, 람다의 모든 매개변수 타입은 생략 - 타입을 알 수 없다는 오류를 낼 때만 해당 타입을 명시 - 람다는 이름이 없고 문서화도 못함. 따라서 코드 자체로 동작이 명확히 설명이 되지 않거나 코드 줄 수가 많아지면 람다를 쓰면 안 됨 - 람다는 한 줄 일 때 가장 좋고, 길어야 세 줄 안에 끝내야 - 람다에서의 this 키워드는 바깥 인스턴스를 가리킴 - 함수 객체가 자신을 참조해야 한다면 반드시 익명 클래스를 써야 - 람다를 직렬화 X 아이템 43. 람다보다는 메서드 참조를 사용하라 - 람다로 할 수 없는 일이라면 메서드 참조로도 할 수 없음 아이템 44. 표준 함수형 인터페이스를 사용하라 # 함수형 인터..