개발공부블로그

스레드 안전성에 대해서는 문서에 synchronized 키워드가 있는지 보면 알 수 있다고 하는데, 보통 Javadoc이 만드는 문서에는 synchronized 키드워가 들어가지 않는데, 거기에는 이유가 있다. synchronized 키워드는 메서드의 구현 상세에 해당하는 정보이며, 공개 API의 일부가 아니기 때문이다. 병렬적으로 사용해도 안전한 클래스가 되려면, 어떤 수준의 스레드 안전성을 제공하는 클래스 인지 문서에 명확하게 남겨야 한다.

• 변경 불가능 - 이 클래스로 만든 객체들은 상수다. 따라서 외부적인 동기화 메커니즘 없이도 병렬적 이용이 가능하다. String, Long, BigInteger 등이 그 예다.
• 무조건적 스레드 안전성 - 변경이 가능하지만 적절한 내부 동기화 메커니즘을 갖추고 있어서 외부적으로 동기화 메커니즘을 적용하지 않아도 병렬적으로 사용할 수 있다. Random, ConcurrentHashMap이 그 예다.
• 조건부 스레드 안전성 - 무조건전 스레드 안전성과 거의 같은 수준이나, 몇몇 스레드는 외부적 동기화가 없이는 병렬적으로 사용할 수 없다. 
• 스레드 안전성 없음 - 해당 객체들은 변경이 가능하다. 이러한 객체들을 병렬적으로 이용하려면 메서드를 호출하는 부분을 클라이언트가 선택한 외부적 동기화 수단으로 감싸야 한다. synchronized를 써야 한다는 뜻인가..?

요약

watit와 notify를 정확하게 사용하는 것이 어렵기 때문에 자바 1.5 플랫폼에서 지원하는 고수준 병행성 유틸리티를 반드시 이용해야 한다. java.util.concurrent에 포함된 이 유틸리티들은 실행자 프레임워크, 병행 컬렉션, 그리고 동기자의 세 가지 범주로 나눌 수 있다.

• 병행 컬렉션은 List, Queue, Map 등의 표준 컬렉션 인터페이스에 대한 고성능 병행 컬렉션 구현을 제공한다. 이 컬렉션들은 병행성을 높이기 위해 동기화를 내부적으로 처리한다. 따라서 컬렉션 외부에서 병행성을 처리하는 것은 불가능하다. 락을 걸어봐야 효과가 없을뿐만 아니라 프로그램만 느려진다. 병행컬렉션에는 예를들어, ConcurrentMap이란 것이 있는데 Map을 확장해서 몇 가지 메서드를 추가하였다. 그 가운데 putIfAnsent(key,value) 메소드는 는 키에 해당하는 값이 없을떄만 주어진 값을 넣고, 이미 있는 경우는 기존 값을 반환한다. 없는 경우에는 null을 반환하기 때문에 반환되는 값을 체크하여 사용하면 효율적이다.
• 동기자는 스레드들이 서로를 기다릴 수 있도록 하여, 상호 협력이 가능하게 한다. 

자바 1.5부터 자바 플랫폼에는 java.util.concurrent가 추가되었다. 이 패키지에는 실행자 프레임워크 라는 것이 들어 있는데, 요연성이 높은 인터페이스 기반 태스크 실행 프레임워크다. 이 프렘워크를 사용하면 스레드를 직접 관리하는 작업 큐를 한 줄의 코드로 생성할 수 있다.

아직은 이해하기가 너무 어렵다.. 추후에 다시 정리해보록 하자..

synchronized 키워드는 특정 메서드나 코드 블록을 한번에 한 스레드만 사용하도록 보장한다. 동기화는 스레드가 일관성이 깨진 객체를 관측할 수 없도록 할 뿐 아니라(하나의 스레드만 이용), 동기화 메서드나 동기화 블록에 진입한 스레드가 동일한 락의 보호 아래 이루어진 모든 변경의 영향을 관측할 수 있도록 보장한다(기존의 스레드가 변경한 내용을 새로운 스레드가 관측 가능). 

 성능을 높이기 위해서는 원자적 데이터를 읽거나 쓸 때 동기화를 피해야 한다는 이야기를 자주 들어봤을 것이다. 상호 배제성뿐 아니라 스레드 간의 안정적 통신을 위해서도 동기화는 반드시 필요하다. 즉 하나의 스레드만 이용할 수 있도록 하는 것의 용도 뿐만아니라 스레드 간의 안정적 통신을 위해서는 동기화를 사용해야 한다는 뜻이다. 자바의 메모리 모델 명세 때문이다. 메모리 모델은 한 스레드가 만든 변화를 다른 스레드가 볼 수 있게 되는 시점과, 그 절차를 규정하기 때문이다. 즉 기존의 스레드가 변경한 내용을 새로운 스레드가 알도록 하는 것을 규정한다는 것.

요약

API 설계자가 예외를 발생할 수 있다고 선언했다면, 그것은 API를 이용할 프로그래머에게 무언가를 알리려는 것이다. 무시하지마라! . 호출 대상 메서드를 빈 CATCH 블록이 붙은 TRY 문으로 감싸면, 예외를 쉽게 무시할 수 있다.

일반적으로 이야기해서, 메서드 호출이 정상적으로 처리되지 못한 객체의 상태는, 메서드 호출전 상태와 동일해야 한다. 이 속성을 만족하는 메서드는 실패원자성을 갖추었다고 한다.

 실패 원자성을 달성하는 방법은 여러가지다. 

• 변경 불가능 객체로 설계하는 방법. 변경 불가능한 객체의 경우, 실패원자성은 덤이다. 메서드 호출이 실패하면 새로운 객체가 만들어지지 못할 수는 있게지만 기존 객체의 일관성이 깨지진 않는다. 변경 가능한 객체의 경우에는 실제 연산을 수행하기 전에 인자 유효성을 검사하는 것이 가장 보편적인 방법이다. 
  

요약

무점검 예외 때문에 프로그램이 죽으면, 시스템은 자동적으로 해당 예외의 스택 추적 정보를 출력한다. 이 정보는 해당 예외 객체의 toString 메서드가 예외 정보를 문자열로 변환한 결과다. 따라서 toString 메서드가 반환하는 문자열에 오류 원인에 관계된 정보를 최대한 많이 담아두는 것이 아주 유용하다.  다시 말해서, 예외의 상세 메세지에는 원인 분석에 이용될 오류 정보가 포착되어 있어야 한다는 것이다.

 오류 정보를 포착해 내기 위해서는, 오류의 상세 메세지에 "예외에 관계된" 모든 인자와 필드의 값을 포함 시켜야 한다. 예를 들어 IndexOutOfBounds Exception의 예외 메세지에는 첨자의 하한과 상한, 그리고 그 범위를 벗어난 첨자값이 포함되어 있어야 한다. 그 정보를 보면 많은 정보를 얻을 수 있기 때문이다. 

 예외의 상세 메세지를 사용자 레벨 오류 메시지와 혼동해서는 안 된다. 사용자 레벨 오류 메시지는 최종 사용자가 이해할 수 있어야 한다. 하지만 예외에  대한 상세 메시지는 프로그래머나 서비스 담당자가 오류 원인을 분석하기 위한 것이다. 따라서 가독성보다는 내용이 훨씬 중요하다.  이런 상세 메시지에 담는 한가지 방법은, 상세한 정보를 요구하는 생성자를 만드는 것이다.