컴포넌트의 스레드 안정성을 안정적으로 확보하고 개발자가 코드 작성 과정에서 실수를 해도 스레드 안정성을 해치지 않도록 도와주는 클래스 구성 방법에 대해 알아봄 4.1 스레드 안전한 클래스 설계 4.1.1 동기화 요구사항 정리 4.1.2 상태 의존 연산 4.1.3 상태 소유권 4.2 인스턴스 한정 4.2.1 자바 모니터 패턴 4.2.2 예제: 차량 위치 추적 4.3 스레드 안전성 위임 4.3.1 예제: 위임 기법을 활요한 차량 추적 4.3.2 독립 상태 변수 4.3.3 위임할 때의 문제점 4.3.4 내부 상태 변수를 외부에 공개 4.3.5 예제: 차량 추적 프로그램의 상태를 외부에 공개 4.4 스레드 안전하게 구현된 클래스에 기능 추가 4.4.1 호출하는 측의 동기화 4.4.2 클래스 재구성 4.5 동기화..

메모리상의 공유된 변수를 여러 스레드에서 서로 사용할 수 있게 하려면 반드시 동기화 기능을 구현해야 한다. 동기화되지 않은 상황에서 메모리상의 변수를 대상으로 작성해둔 코드가 '반드시 의도한대로 동작할 것이다'라고 단정지을 수 없다. 여러 스레드에서 공동으로 사용하는 변수에는 항상 적절한 동기화 기법을 적용한다. 특정 변수에 값을 저장하거나 읽는 코드가 여러 스레드에서 앞서거니 뒤서거니 실행되면 이전에 저장해뒀던 값을 가져가지 못할 수 있음 예제 3.1 변수를 공유하지만 동기화되지 않은 예제 ready 변수의 값을 읽기 스레드에서 영영 읽지 못할 수 있어서 무한 반복에 빠질 수 있다. 자바 메모리 모델에서는 별다른 동기화 구조가 잡혀있지 않으면 컴파일러가 직접 코드 실행 순서를 조절하여 레지스터 캐시, ..

자바 exception에는 checked exception과 unchecked exception 두 가지가 있다. checked exception - 메소드 시그니쳐에서 명시되어 있어야 하고 그 예외를 발생시킬 수 있는 메소드를 호출하는 쪽에서 예외에 대한 처리를 필수적으로 해줘야 한다.(try/catch or throw) - Exception 클래스를 상속받아 만들면 checked exception이 된다. unchecked exception - 메소드 시그니쳐에 명시되어 있을 필요는 없고 그 예외를 발생시킬 수 있는 메소드를 호출하는 쪽에서 예외에 대한 처리를 필수적으로 해줄 필요는 없다. - RuntimeException 클래스를 상속받아 만들면 unchecked exception이 된다. - un..

[자바 병렬 프로그래밍 - 2장 스레드 안정성] 요약 정리 - 스레드 안정한 코드를 작성하는 것은 근본적으로는 상태, 특히 공유되고 변경할 수 있는 상태에 대한 접근을 관리하는 것 - 스레드 안전성은 코드를 보호하는 것이 아닌, 데이터에 제어 없이 동시에 접근하는 것을 막는 것 - 객체를 스레드에 안전하게 만들려면 동기화를 통해 변경할 수 있는 상태에 접근하는 과정을 조율해야함 - 스레드가 하나 이상 상태 변수에 접근하고 그 중 하나라도 변수에 값을 쓰면, 해당 변수에 접근할 때, 관련된 모든 스레드를 동기화를 통해 조율해야함 - 기본 수단은 synchronized 키워드로서 배타적인 락을 통해 보호 기능을 제공함 - 만약 여러 스레드가 변경할 수 있는 하나의 상태 변수를 적절한 동기화 없이 접근하면 그..

[자바 병렬 프로그래밍 - 1장 개요] 요약 정리 1.1 작업을 동시에 실행하는 일에 대한 간략한 역사 - 병렬 프로그래밍의 중요성 스레드는 멀티프로세서 시스템의 능력을 최대한 끌어낼 수 있는 가장 쉬운 방법 프로세서 개수가 늘어날수록 여러 작업을 동시에 실행하는 일이 더욱 중요함 - 여러 프로그램을 동시에 실행하는 운영체제를 개발하게 된 요인 1. 자원 활용 입출력과 같이 외부 동작 끝나기를 대기하는 경우 자원을 활용할 수 없음 기다리는 동안 다른 프로그램을 실행하도록 하는게 효율적 2. 공정성 여러 사용자와 프로그램이 컴퓨터 내 자원에 대해 동일한 권한을 가질 수 있음 3. 편의성 여러 작업을 처리하는 하나의 프로그램 작성보다 각기 일을 처리하고 조율하는 프로그램을 작성하는 것이 쉽고 바람직함 - 프..

나쁜 설계의 경우 다음과 같은 요소들을 가지고 있다. 경직성 : 무엇인듯 하나를 바꿀 때마다 반드시 다른 것도 바꿔야하고 변화의 사슬이 끊이지 않아 시스템 변경이 힘듦.부서지기 쉬움 : 시스템 한 부분을 변경하면 전혀 상관없는 다른 부분에 이상이 생김.부동성 : 시스템이 여러 컴포넌트로 분해되어 있어 다른 시스템에서 재사용하기 힘듦.끈끈함 : 편집-컴파일-테스트 순환을 한 번 도는 시간이 엄청나게 길다.쓸데없이 복잡함 : 괜히 머리를 굴려서 짠 코드 구조가 많다.필요 없는 반복 : 복사/붙여넣기, 중복코드가 많음.불투명함 : 코드 작성 의도가 불분명하다, 코드와 그에 대한 설명에 괴리가 있다. 잘못 관리한 의존 관계가 위 요소들의 원인이다.위와 같은 요소들을 발견하면 다음 원칙들을 이용하여 개선을 해보자..