wedul

스레드 그룹(thread group)은 원래 applet을 격리시켜 보안문제 해결할 목적으로 만들어졌으나 성공하지 못했다. 그러면 이런 스레드 그룹은 왜 남아있는가? 아예 쓸곳이 없는가? 그렇지는 않다. 스레드 기본연산을 여러 스레드에 동시에 적용할 수 있도록 하는 기능을 가지고 있다. 하지만 대부분이 deprecated 되었다. 결론을 이야기하자면 이미 다 페기가 되어버린 기능이다. 그렇기 때문에 신경쓸 것 없이 사용하지 말아야한다. 출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1)

실행해야 할 스레드가 많을 경우 어떠한 스레드를 얼마나 오랫동안 실행할지 결정은 스레드 스케줄러가 진행한다. 운영체제마다 스레드 스케줄러는 다르기 때문에 아무리 운영체제에서 효율적으로 진행한다고 하더라고 이에 의존하여 프로그램을 제작해서는 안된다. 정확하고 좋은 스레드 프로그램은 의존하는것이 아니라 실행가능한 스레드의 개수가 프로세수 개수보다 넘지 않도록 제작하는 것이다. 그렇게되면 스레드 스케줄러가 순차적으로 스레드를 실행시켜줄뿐 정책에 신경쓰지않는다. 그렇다면 실행중인 스레드의 개수를 최대한 줄일 수 있는 방법은 무엇일까? 바로 사용하지 않는 스레드는 실행하지 않고 정지하거나 종료해야한다. 그래서 바로 직전에 공부했던 스레드 풀을 사용하여 적절하게 스레드를 관리하면 좋은 프로그램을 만들 수 있다. 그..

Lazy initialization(초기화 지연)은 필드 초기화를 실제로 그 값이 쓰일 때까지 미루는 것이다. 대부분 초기화 지연의 이유는 초기화의 비용이 증가하고 사용빈도가 특별한 경우에 사용하는 필드에 대해서 그렇게 적용한다. 만약 그렇지 않은 경우에도 초기화 지연을 사용하면 어떨까?이럴 경우 클래스를 초기화하고 객체를 생성하는 비용은 줄이지만 필드 사용 비용은 증가시킨다. 그럼 동기화가 필요한 다중 스레드 환경에서는 초기화 지연은 어떻게 구현해야할까? 생각만 해도 어렵다. 몇가지 방법을 살펴보자.우선 초기화 지연을 사용하지 않고 진행하는 일반적인 초기화는 다음과 같다.1234567891011 public class TestClass { // 일반적인 초기화 기법 // 클래스가 처음 로드될 때 바로 ..

클래스를 사용할 때 클래스의 객체와 정적 메서드가 병렬적으로 이용되었을 때, 어떠한 부작용이 있을 수 있는지 안전한지에 대한 정보가 없으면 추후에 큰 문제를 야기할 수있다. JavaDoc에서 synchronized 키워드를 통해 병렬설 지원 여부를 확인할 수있다고 알고 있으나 실상 그렇지 않다. 왜냐하면 Javadoc이 만드는 문서에는 Javadoc이 들어가지 않는다. 왜냐하면 synchronized 키워드는 메서드의 구현 상세에 해당하는 정보이며, 공개 API의 일부가 아니기 때문이다. 그렇기 때문에 synchronized 키워드를 통해 판단해서는 안되고 병렬적으로 사용해도 되는지의 여부는 문서에 남겨져 있어야 한다. 출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사..

멀티 쓰레드 환경에서 wait와 notify를 사용할 경우에 주의가 필요하다. 하지만 그것을 효율적으로 사용하기에는 많은 어려움이 따른다. 그렇기 위해서 wait와 notify를 정확하게 사용하기 위해서는 high-level util(고수준 유틸리티)을 사용해야 한다.이런 고수준 유틸리티들은 Executor, Concurrent Colloection, Synchronizer를 통해 사용할 수 있다.그중 Conncurrent Collenction (병행 컬렉션)에 대해 알아보자. 대부분에 컬렉션 Map, List, Queue등은 병행 컬렉션을 제공한다. 병행성 컬렉션대표적으로 Map에서 제공하는 ConcurrentMap이다. 그중 putIfAbsent(key, value) 메서드가 대표적이다. 이 메서드는..

여러 쓰레드를 실행해야할 때, 큐에 넣고 작업을 진행하거나 할 수 있으면 더욱 효율적으로 관리 할 수있다. 그래서 자바 1.5부터 자바 플랫폼에는 java.util.concurrent가 추가되었다. 이 패키지에는 Executor Framework가 들어 있는데 이는 인터페이스 기반 task 실행 프레임워크이다. 해당 Executor를 실행하기 위해서는 다음과 같이 입력하면 된다.1234567ExecutorService executor = Executors.newSingleThreadExecutor(); executor. @Override public void run() { System.out.println("test"); }});Colored by Color Scriptercs 그리고 만약 executo..

동기화 시에 너무 많은 동기화 블록을 사용할 경우에 데드락이 걸리거나 성능저하 등등 문제를 일으킬 수 있는 소지들이 몇 가지 있다. 특히 동기화 영역안에서 수행되는 작업의 양을 가능한 줄여야 한다. 자바에서는 동기화에 대한 비용처리가 그나마 잘되어있지만 잘 사용해야 하는 이유는 잘못된 동기화 사용은 각 쓰레드들의 메인 메모리 접근에 대한 지연시간을 늘릴 수 있기 때문에 비용이 증가할 수 있다. 또한 클래스 내에서 동기화를 수행하는 것이 외부에서 객체 호출 시 사용하는것 보다 높은 병행성을 달성 할 수 있을 때문 진행해야한다. 다시말하자면 필요할 때 해당 메서드등을 호출하여 동기화를 실행해야지 해당 메서드 자체를 동기화 하는것은 좋지 않다. 예를 들면 기존에는 StringBuffer를 사용하여 내부적으로 ..

우리는 동시에 사용이 가능한 객체에 대해서 synchronized키워드를 사용하여 락을 걸어 코드 블록을 한번에 하나의 스레드만 접근할 수 있도록 한다. 이런 동기화를 적절하게 사용하면 모든 메서드가 항상 객체의 일관된 상태만 바라보도록 할 수 있다. 하지만 동기화 없이는 한 스레드가 만든 변화를 다른 스레드가 확인할 수 없다. 동기화는 스레드가 일관성이 깨진 객체를 관측할 수 없도록 할 뿐 아니라, 동기화 메서드나 동기화 블록에 진입한 스레드가 동일한 락의 보호 아래 이루어진 변경의 영향을 관측할 수 있도록 보장한다. 그렇기 때문에 특정 객체의 값을 다른 쓰레드가 읽기를 원한다면 동기화를 무조건 진행해야한다.즉, 변경 가능한 공유 데이터에 대한 접근을 동기화 해야한다. 다음 예를 보자.123456789..

예외가 발생한 다음에도 기존에 사용하던 객체의 상태가 그대로 유지되는 것이 좋다.쉽게 이야기하면, 메서드 호출이 정상적으로 처리되지 못한 객체의 상태는 메서드 호출 전 상태와 동일해야한다. 이런 속성을 만족하는 메서드는 실패 원자성(failure atomicity)을 갖추었다고 한다. 이런 실패원자성을 해소하기 위한 방법을 알아보자. 먼저 간단하게 변경 불가능 객체로 설계하는 것이다.-> 왜냐하면 원자성이 있는 객체는 생성된 이후에는 변경되지 않기 때문에 오류가 발생한다고 해도 원자성이 깨지지 않는다. 그럼 변경 가능한 객체의 경우 어떻게 해야할까?-> 이는 실제 연산을 수행하기전에 인자 유효성을 미리 검사하는 방법이다. (객체가 변경되기 전에 예외를 발생시켜 발생하는 것을 막는것이다.) 아래 예를 살펴..

개발을 진행하다보면 예기치 못한 상황에서 에러가 자주 발생한다. 에러가 발생하는 것을 다 알고 차단할수있다면 정말 바람직한 프로그램이라고 할 수있을 것이다.하지만 그럴수가 없기때문에 에러를 관리하고 효율적으로 에러정보를 전달하는것이 중요하다. 정확한 에러정보를 전달하는것이 빠르게 문제를 해결하는 실마리가 될것이다.그래서 에러가 발생되었을 때 오류의 상세 메시지에 예외에 관련된 모든 인자와 필드값을 포함시켜야 한다. 예를 들어, IndexOutOfBounds Exception의 경우 해당 범위를 벗어난 인자값과 하한과 상한값도 포함되어있어야 한다. 그러면 정확히 어떻게 오류가 발생된 것인지 알기가 쉬워진다. 하지만 관련된 데이터를 담는 것이 중요하지만 잘못사용하면 별로 도움이 되지 않을 수 있다.그리고 이..