[Java Concurrency] 성능, 확장성 #1 [Java Concurrency] 성능, 확장성 - 스레드를 사용하는 가장 큰 목적은 바로 성능을 높이고자 하는 것이다. 스레드를 사용하면 시스템의 자원을 훨씬 효율적으로 활용할 수 있고, 앱으로 하여금 시스템이 갖고 있는 능력을 최대한 사용하게 할 수 있다. 그와 동시에 기존 작업이 실행되고 있는 동안 새로 등록된 작업을 즉시 실행할 수 있는 준비를 갖추고 있기 때문에 앱의 응답 속도를 향상시킬 수 있다. - 성능을 높이는 방법은 대부분 앱의 내부 구조를 복잡하게 만들어야 하는 경우가 많고, 따라서 안전성과 활동성에 문제가 생길 가능성도 적지 않다. 최악의 경우에는 성능을 높이기 위해 적용한 프로그래밍 기법 때문에 프로그램의 다른 부분에서 역효과를 가져오거나 성능상에 문제를 일으킬 수도 있다. - 성능.. 2017. 5. 3. [Java Concurrency] 구성 단위 #2 [Java Concurrency] 구성 단위 #2 5.4. 블로킹 메소드, 인터럽터블 메소드 - 스레드는 여러 가지 원인에 의해 블록 당하거나, 멈춰질 수 있다. 스레드가 블록되면 동작이 멈춰진 다음 블록된 상태(BLOCKED, WAITING, TIMED_WAITING) 가운데 하나를 갖게 된다. 블로킹 연산은 단순히 실행 시간이 오래 걸리는 일반 연산과는 달리 멈춘 상태에서 특정한 신호를 받아야 계속해서 실행할 수 있는 연산을 말한다. ( I/O 작업 끝나기를 기다리거나, 기다리던 락을 확보하거나, 다른 스레드의 작업 결과를 받아오는 등의 신호 ) - Thread 클래스는 해당 스레드를 중단시킬 수 있도록 interrupt 메소드를 제공하며, 해당 스레드에 인터럽트가 걸려 중단된 상태인지를 확인할 수 .. 2017. 4. 21. [Java Concurrency] 구성 단위 #1 [Java Concurrency] 구성 단위 #1 5.1. 동기화된 컬렉션 클래스 - 동기화되어 있는 컬렉션 클래스의 대표 주자는 Vector 와 Hashtable 이다. - JDK 1.2 부터는 Collections.synchronizedXxx 메소드를 사용해 이와 비슷하게 동기화되어 있는 몇 가지 클래스를 만들어 사용할 수 있게 됐다. 이와 같은 클래스는 모두 public 으로 선언된 모든 메소드를 클래스 내부에 캡슐화해 내부의 값을 한 번에 한 스레드만 사용할 수 있도록 제어하면서 스레드 안전성을 확보하고 있다. - 동기화된 컬렉션 클래스는 스레드 안전성을 확보하고 있기는 하다. 하지만 여러 개의 연산을 묶어 하나의 단일 연산처럼 활용해야 할 필요성이 항상 발생한다. - 동기화된 컬렉션 클래스는 대.. 2017. 4. 20. [Java Concurrency] 객체구성 [Java Concurrency] 객체구성 4.1. 스레드 안전한 클래스 설계 - 객체가 갖고 있는 여러 가지 정보를 해당 객체 내부에 숨겨두면 전체 프로그램을 다 뒤져볼 필요 없이 객체 단위로 스레드 안전성이 확보되어 있는지 확인할 수 있다. - 클래스가 스레드 안전성을 확보하도록 설계하고자 할 때에는 다음과 같이 세 가지를 고려해야 한다. 객체의 상태를 보관하는 변수가 어떤 것인가? 객체의 상태를 보관하는 변수가 가질 수 있는 값이 어떤 종류, 어떤 범위에 해당하는가? 객체 내부의 값을 동시에 사용하고자 할 때, 그 과정을 관리할 수 있는 정책 - n 개의 변수를 갖는 객체의 상태는 n개 변수가 가질 수 있는 값의 전체 조합이다. A라는 객체 내부에 다른 객체 B를 가리키는 변수를 사용하고 있다면, .. 2017. 4. 18. [Java Concurrency] 객체공유 [Java Concurrency] 객체공유 3.1. 가시성 - 일반적으로 특정 변수의 값을 가져갈 때 다른 스레드가 작성한 값을 가져갈 수 있다는 보장도 없고, 심지어는 값을 읽지 못 할 수도 있다. 메모리상의 공유된 변수를 여러 스레드에서 서로 사용할 수 있게 하려면 반드시 동기화 기능을 구현해야 한다. - 재배치(reordering) 현상을 조심해야 한다. 재배치 현상은 특정 메소드의 소스코드가 100% 코딩된 순서로 동작한다는 점을 보장할 수 없다는 점에 기인하는 문제이다. 단일 스레드로 동작할 때는 차이점을 전혀 알아챌 수 없지만 여러 스레드가 동시에 동작하는 경우에는 확연하게 나타날 수 있다. - 동기화 기능을 지정하지 않으면 컴파일러나 프로세서, JVM 등이 프로그램 코드가 실행되는 순서를 임.. 2017. 4. 17. [Java Concurrency] 스레드 안전성 [Java Concurrency] 스레드 안전성 - 스레드에 안전한 코드를 작성하는 것은 근본적으로는 상태, 특히 공유되고 변경할 수 있는 상태에 대한 접근을 관리하는 것이다. - 공유된 상태에 대한 접근을 동기화해야 한다는 원칙에 "특별한" 경우의 예외가 있다고 생각하고 싶겠지만, 그런 유혹은 버려야 한다. - 만약 여러 스레드가 변경할 수 있는 하나의 상태 변수를 적절한 동기화 없이 접근하면 그 프로그램은 잘못된 것이다. 이렇게 잘못된 프로그램을 고치는 데는 세 가지 방법이 있다. 1. 해당 상태 변수를 스레드 간에 공유하지 않거나 2. 해당 상태 변수를 변경할 수 없도록 만들거나 3. 해당 상태 변수에 접근할 땐 언제나 동기화를 사용한다. - 스레드 안전성을 확보하기 위해 나중에 클래스를 고치는 것.. 2017. 4. 14. [Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 [Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 - 클래스를 설계할 때 클래스가 Serializable 을 구현하면서 기본 직렬화 형태를 사용한다면, 나중에 함부로 버릴 수 없고, 그 직렬화 형태를 계속 유지해야 할 가능성이 높다. - 적합 여부를 우선적으로 고려해보고 기본 직렬화 형태를 수용하자. 기본 직렬화 형태는 유연성, 성능, 정확성의 관점에서 타당하다는 결정이 섰을 때 사용해야 한다. 일반적으로 말하면, 우리가 독자적인 직렬화 형태를 설계한다고 할 때 하게될 인코딩과 대부분 같은 경우에만 기본 직렬화 형태를 사용해야 한다. - 이상적인 객체 직렬화 형태는 그 객체가 표현하는 논리적 데이터만 포함한 것이다. - 기본 직렬화 형태는 객체의 물리적 표현이 논리적인 내용과 동일할 .. 2017. 3. 23. [Effective Java] 늦 초기화를 분별력 있게 사용하자 [Effective Java] 늦 초기화를 분별력 있게 사용하자 - 늦 초기화는 양날의 검이다. 클래스를 초기화하거나 인스턴스를 생성하는 비용은 줄여주지만, 그 대신 늦게 초기화되는 필드의 접근 비용은 증가시킨다. 늦 초기화는 실제로 성능을 저하시킬 수 있다. ( 다른 많은 최적화 처럼 ) - 늦 초기화는 나름의 용도가 있다. 만일 어떤 필드가 어떤 클래스 인스턴스의 일부로만 사용되고, 그러면서 그 필드의 초기화 비용이 많이 든다면 늦 초기화가 좋을 수 있다. 확실히 하기 위해서는 역시나 성능을 측정하는 것이 좋겠다. - 다중 스레드의 경우에는 늦 초기화가 쉽지 않다. 만일 두 개 이상의 스레드가 늦게 초기화되는 필드를 공유한다면, 어떤 형태로든 동기화 하는 것이 중요하며, 동기화를 하지 않으면 심각한 .. 2017. 3. 16. [Effective Java] 스레드 안전을 문서화 하자. [Effective Java] 스레드 안전을 문서화 하자. - 클래스 행동을 문서화하지 않으면, 프로그래머는 가정에 의존해서 그 클래스를 사용해야 한다. 만일 그런 가정들이 잘못되면, 그로 인한 프로그램은 불충분한 동기화나 과도한 동기화를 하게 될 것이다. 어떤 경우든, 심각한 에러가 유발될 수 있다. - 메소드 선언부의 synchronized 변경자는 메소드의 상세 구현 부분이지 외부로 제공되는 API 가 아니다. 즉 Javadoc 에 synchronized 가 공개되지 않는다. synchronized 변경자가 있다는 것이 스레드 안전을 문서화하기에 충분한 것은 아니다. 동시적 사용을 안전하게 하려면, 해당 클래스가 어떤 수준의 스레드 안전을 지원하는지 명확하게 문서화해야 한다. - 다음은 스레드 안전.. 2017. 3. 14. 반응형 이전 1 2 3 다음
