본문 바로가기
[Effective Java] wait 와 notify 대신 동시성 유틸리티를 사용하자. [Effective Java] wait 와 notify 대신 동시성 유틸리티를 사용하자. - wait 와 notify 를 사용할 이유가 거의 없다. 자바 1.5 배포판 기준으로 고수준 동시성 유틸리티를 제공한다. wait와 notify 를 올바르게 사용하기 어렵다면, 그 대신에 고수준 동시성 유틸리티를 사용해야 한다. - java.util.concurrent 패키지의 고수준 유틸리티는 세 부류로 나누어진다. 실행자 프레임워크(executor framework) 동시적 컬렉션 및 동기자(synchronizer) - 동시적 컬렉션은 List, Queue, Map 과 같은 표준 컬렉션 인터페이스를 고성능의 동시적 구현체로 제공한다. 높은 동시성을 제공하기 위해 이 구현체들은 내부적으로 자기 나름의 동기화를 한.. 2017. 3. 13.
[Effective Java] 지나친 동기화는 피하자 [Effective Java] 지나친 동기화는 피하자 - 지나친 동기화는 성능을 저하시키고 교착상태(dead lock)을 유발시키며, 심지어 예기치 않은 행동을 초래할 수 있다. - 동기화된 메소드나 블록 안에서 절대로 클라이언트에게 제어권을 넘기면 안 된다. 즉, 동기화된 영역 내부에서는 오버라이딩된 메소드를 호출하지 않아야 하며, 함수 객체의 형태로 클라이언트가 제공하는 메소드도 호출하지 말아야 한다. 동기화된 영역을 갖는 클래스의 관점에서 그런 메소드들은 매우 이질적인 녀석들이다. 그 메소드가 무슨 일을 하는지 알지 못하며, 이질적인 일을 하는 것을 제어하지도 못한다. 외계인 메소드가 하는 일에 따라 다르겠지만, 동기화된 영역에서 그 메소드를 호출하면 예외나 dead lock 또는 데이터 손상까지 .. 2017. 3. 9.
[Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16.
[Effective Java] 문자열 결합의 성능 저하를 주의하자. [Effective Java] 문자열 결합의 성능 저하를 주의하자. - 문자열 결합 연산자(+)는 편리하지만 크기 조정이 안 된다는 단점이 있다. 문자열 결합 연산자를 n개의 문자열에 반복적으로 사용하면 n의 제곱에 비례하는 시간이 소요된다. String 이 불변(immutable)이기 때문이다. - 원하는 성능을 얻으려면 String 대신 StringBuilder 를 사용하자. - StringBuilder 를 결과를 충분히 저장할 만큼의 크기로 만들면 성능에 더 유리하다. 미리 산정된 만큼의 크기로 StringBuilder 를 생성하지 않고, 기본 크기로 생성해도 + 형태보다 여전히 50배 이상 빠르다. - StringBuilder 를 사용하기 싫다면 문자 타입을 저장하는 배열을 사용하거나, 문자열을 .. 2017. 2. 7.
[Effective Java] 다른 타입을 쓸 수 있는 곳에서는 String 사용을 피하자. [Effective Java] 다른 타입을 쓸 수 있는 곳에서는 String 사용을 피하자. - String 으로 다른 값 타입을 대체하는 것은 좋지 않다. 파일, 네트웍, 키보드 입력으로부터 데이터가 프로그램으로 전달될 떄 문자열 형식인 경우가 많고, 그것을 그대로 놔두려는 경향이 있다. 그러나 그것은 실제로 데이터가 원문 그대로일 때만 옳다. 만일 데이터가 숫자라면 int, float, BigInteger 와 같이 적합한 숫자 타입으로 변환되어야 한다. - String 으로 enum 타입을 대체하는 것은 좋지 않다. - String 으로 집합(aggregate) 타입을 대체하는 것은 좋지 않다. ex) className + "#" + value 이런 경우 문자열 분석을 해야 해 속도가 느리고, 코드가.. 2017. 2. 6.
[Effective Java] 정확한 계산에는 float 이나 double 타입을 쓰지 말자. [Effective Java] 정확한 계산에는 float 이나 double 타입을 쓰지 말자. - float, double 은 이진 부동소수점 연산을 수행하는데, 넓은 범위의 수에 대해 정확한 근사치를 빨리 산출하기 위해 설계되었다. 그러나 정확한 결과를 제공하지 않으므로, 근사치가 아닌 정확한 결과가 필요한 곳에 사용하면 안된다. float 과 double 타입은 돈 계산에는 특히 부적당하다. - 돈 계산할 때 올바른 답을 구하려면 BigDecimal, int, long 타입 중 하나를 사용해야 한다. - BigDecimal 은 정확한 연산을 제공하지만 두 가지 단점이 있다. 1. 기본 데이터 타입을 사용할 떄보다 불편하다. 2. 실행 속도가 느려진다. - BigDecimal 을 사용하지 않으려면, i.. 2017. 1. 31.
[Effective Java] 라이브러리를 배우고 사용하자. [Effective Java] 라이브러리를 배우고 사용하자. - 표준 라이브러리를 사용하면, 그것을 작성한 전문가들의 지식과 더 앞서 사용한 사람들의 경험을 이용하는 것이다. - 라이브러리를 사용하면 해결책을 작성하는 쓸데없는 시간을 낭비할 필요가 없다. - 라이브러리를 사용하면 우리의 노력 없이도 라이브러리의 성능이 지속적으로 개선된다. 또 새로운 기능이 계속 추가된다. - 라이브러리를 사용하면 우리 코드를 주류에 둠으로써 많은 개발자들에 의해 더욱 가독성이 좋아지고, 유지보수 가능하며, 재 사용 가능하게 된다. - 라이브러리를 사용하면 많은 장점이 있지만 많은 개발자들이 그렇게 하지 않는다. 원하는 기능이 라이브러리에 있는지 모르기 때문일 것이다. - 라이브러리는 너무 커서 모든 문서를 파악하기는 어.. 2017. 1. 30.
[Effective Java] 종전의 for 루프보다는 for-each 루프를 사용하자. [Effective Java] 종전의 for 루프보다는 for-each 루프를 사용하자. - for-each 문은 Iterable 인터페이스를 구현하는 어떤 객체도 반복 처리가 가능하다. Iterable 은 다음과 같이 정의된 interface 이다. public interface Iterable{ Iterator iterator();} Iterable 인터페이스 구현은 어렵지 않다. Summary for-each 루프는 종전 for 루프에 비해 많은 장점을 제공한다. 성능 저하가 없으면서 명료하고 버그를 방지해준다. for-each 루프를 사용할 수 없는 경우는 3 가지가 있다. 1. 필터링(filtering) - 어떤 컬렉션의 요소들을 오가면서 선택된 요소들을 삭제할 필요가 있다면 명시적 iterat.. 2017. 1. 26.
[Effective Java] null 대신 비어있는 배열이나 컬렉션을 반환하자. [Effective Java] null 대신 비어있는 배열이나 컬렉션을 반환하자. - 비어있는 배열이나 컬렉션 대신 null 을 반환하는 메소드를 사용할 때는 null checking 을 하는 복잡하고 긴 형태의 코드를 작성해야 한다. 또한 클라이언트 코드를 작성하는 프로그래머가 반환 값인 null 을 처리하는 코드 작성을 잊어버리면 NullPointerException 이 발생하기 쉽다. - 비어있는 배열보다는 null 값을 반환하는 것이 좋다는 주장도 있다. 배열을 생성하는 비용이 들지 않기 때문이다. 그러나 두 가지 면에서 이는 틀렸다. 1. 해당 메소드가 정말로 성능 문제의 원인인지 성능 프로파일에 나타나지 않으면 이런 경우에는 성능 우려를 할 것이 못 된다. 2. 길이가 0인 배열은 불변 객체이.. 2017. 1. 19.
반응형