본문 바로가기
[Java Concurrency] 동기화 클래스 구현 14.1. 상태 종속성 관리 - 병렬 객체의 상태 종속적인 메소드는 선행 조건이 만족하지 않았을 때 오류가 발생하는 문제에서 비켜날 수도 있겠지만, 비켜나는 일보다는 선행 조건을 만족할 때까지 대기하는 경우가 많아진다. - 자바에 내장된 조컨 큐 메커니즘(condition queue mechanism)은 실행 중인 스레드가 특정 객체가 원하는 상태에 진입할 때까지 대기할 수 있도록 도와주며, 원하는 상태에 도달해서 스레드가 계속해서 실행할 수 있게 되면 대기 상태에 들어가 있던 스레드를 깨워주는 역할도 담당한다. - 일단 선행 조건을 만족하지 않았다면 락을 다시 풀어줘야 다른 스레드에서 상태 변수를 변경할 수 있다. 만약 락을 풀어주지 않고 계속 잡고 있다면 다른 스레드에서 상태 변수의 값을 변경할 수 .. 2017. 5. 8.
[Java Concurrency] 명시적인 락 13.1. Lock 과 ReentrantLock - Lock 인터페이스는 암묵적인 락과 달리 조건 없는(unconditional)락, 폴링 락, 타임아웃이 있는 락, 락 확보 대기 상태에 인터럽트를 걸 수 있는 방법 등이 포함돼 있으며, 락을 확보하고 해제하는 모든 작업이 명시적이다. - public interface Lock{ void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException; void unlock(); Condition newCondition(); } - Reentran.. 2017. 5. 5.
[Java Concurrency] 성능, 확장성 #2 [Java Concurrency] 성능, 확장성 #2 11.4. 락 경쟁 줄이기- 작업을 순차적으로 처리하면 확장성(scalability)을 놓치고, 작업을 병렬로 처리하면 컨텍스트 스위칭에서 성능에 악영향을 줄 수 있다. 따라서 락을 놓고 경쟁하는 상황이 벌어지면 순차적으로 처리함과 동시에 컨텍스트 스위칭도 많이 일어나므로 확장성과 성능을 동시에 떨어뜨리는 원인이 된다. 즉 락 경쟁을 줄이면 줄일수록 확장성과 성능을 함께 높일 수 있다. - 병렬 앱에서 확장성에 가장 큰 위협이 되는 존재는 바로 특정 자원을 독점적으로 사용하도록 제한하는 락이다. - 락을 두고 발생하는 경쟁 상황에는 크게 두 가지를 생각해 볼 수 있다. 락을 얼마나 빈번하게 확보하려고 하는지, 한 번 확보하고 나면 해제할 때까지 얼마나.. 2017. 5. 4.
[Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 [Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 - 클래스를 설계할 때 클래스가 Serializable 을 구현하면서 기본 직렬화 형태를 사용한다면, 나중에 함부로 버릴 수 없고, 그 직렬화 형태를 계속 유지해야 할 가능성이 높다. - 적합 여부를 우선적으로 고려해보고 기본 직렬화 형태를 수용하자. 기본 직렬화 형태는 유연성, 성능, 정확성의 관점에서 타당하다는 결정이 섰을 때 사용해야 한다. 일반적으로 말하면, 우리가 독자적인 직렬화 형태를 설계한다고 할 때 하게될 인코딩과 대부분 같은 경우에만 기본 직렬화 형태를 사용해야 한다. - 이상적인 객체 직렬화 형태는 그 객체가 표현하는 논리적 데이터만 포함한 것이다. - 기본 직렬화 형태는 객체의 물리적 표현이 논리적인 내용과 동일할 .. 2017. 3. 23.
[Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16.
[Effecitve Java] 네이티브 메소드를 분별력 있게 사용하자. [Effecitve Java] 네이티브 메소드를 분별력 있게 사용하자. - JNI 는 네이티브 메소드를 호출할 수 있게 해준다. 네이티브 메소드는 C, C++ 과 같은 네이티브 프로그래밍 언어로 작성한 특별한 메소드를 말한다. - 지금까지 네이티브 메소드의 주용도는 세가지였다. 레지스트리와 파일 락 같은 특정 플랫폼 관리시스템의 접근을 제공 레거시 데이터를 제공할 수 있는 레거시 코드로 된 라이브러리의 접근 제공 성능 향상을 위해 어플리케이션의 일부를 네이티브 언어로 작성하는 데 사용 - 자바가 발전하면 기존의 네이티브 메소드만이 할 수 있었던 일을 많이 대체하였다. java.util.prefs 패키지가 레지스트리 기능을 제공. java.awt.SystemTray 가 데스크톱 시스템의 휴지통 영역의 접근.. 2017. 2. 14.
[Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. [Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. - 리플렉션은 여러모로 강력한 기능을 제공한다. 하지만 이런 강력함은 다음의 대가들을 수반한다. 컴파일 시점에 가능한 타입 확인의 장점이 없어진다. 재귀적인 접근을 필요로 하는 코드는 알아 보기 어렵고 길다. 처리 성능이 늦다. - 사실 리플렉션은 컴포넌트 기반의 어플리케이션 개발 도구용으로 설계되었다. 따라서 일반적으로 런타임에서는 리플렉션을 이용해서 재귀적으로 사용하면 안된다. - 리플렉션이 필요한 복잡한 애플리케이션은 다음과 같다. 클래스 브라우저 객체 조사기 코드 분석 도구 RPC - 리플렉션을 지극히 제한된 형태로만 사용하여 비용이 거의 수반되지 않도록 한다면 리플렉션의 많은 장점을 얻을 수 있다. 예를 들어 컴파일 시점에는 쓸.. 2017. 2. 13.
[Effective Java] 문자열 결합의 성능 저하를 주의하자. [Effective Java] 문자열 결합의 성능 저하를 주의하자. - 문자열 결합 연산자(+)는 편리하지만 크기 조정이 안 된다는 단점이 있다. 문자열 결합 연산자를 n개의 문자열에 반복적으로 사용하면 n의 제곱에 비례하는 시간이 소요된다. String 이 불변(immutable)이기 때문이다. - 원하는 성능을 얻으려면 String 대신 StringBuilder 를 사용하자. - StringBuilder 를 결과를 충분히 저장할 만큼의 크기로 만들면 성능에 더 유리하다. 미리 산정된 만큼의 크기로 StringBuilder 를 생성하지 않고, 기본 크기로 생성해도 + 형태보다 여전히 50배 이상 빠르다. - StringBuilder 를 사용하기 싫다면 문자 타입을 저장하는 배열을 사용하거나, 문자열을 .. 2017. 2. 7.
[Effective Java] 정확한 계산에는 float 이나 double 타입을 쓰지 말자. [Effective Java] 정확한 계산에는 float 이나 double 타입을 쓰지 말자. - float, double 은 이진 부동소수점 연산을 수행하는데, 넓은 범위의 수에 대해 정확한 근사치를 빨리 산출하기 위해 설계되었다. 그러나 정확한 결과를 제공하지 않으므로, 근사치가 아닌 정확한 결과가 필요한 곳에 사용하면 안된다. float 과 double 타입은 돈 계산에는 특히 부적당하다. - 돈 계산할 때 올바른 답을 구하려면 BigDecimal, int, long 타입 중 하나를 사용해야 한다. - BigDecimal 은 정확한 연산을 제공하지만 두 가지 단점이 있다. 1. 기본 데이터 타입을 사용할 떄보다 불편하다. 2. 실행 속도가 느려진다. - BigDecimal 을 사용하지 않으려면, i.. 2017. 1. 31.
반응형

티스토리툴바