본문 바로가기
[Java] What is "CopyOnWriteArrayList" [Java] What is "CopyOnWriteArrayList" http://developer.android.com/reference/java/util/concurrent/CopyOnWriteArrayList.html - Thread-safe 한 random access list. - Read 는 block 이 걸리지 않는다. addAll, clear 와 같은 aggregate operation 은 atomic 하다. - Iterator 를 사용할 때는 copy 본을 사용하기 때문에 ConcurrentModificationException 이 절대 발생하지 않는다. 대신 Iterator 가 최근 state 를 항상 반영하는 것은 아니다. - Iterator 가 copy 본이기 때문에 iterator .. 2017. 2. 22.
[Effective Java] 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자. 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자. - 자바 언어는 다음 세 종류의 예외를 던질 수 있다. checked exception, runtime exception, error - 메소드 호출자가 당연히 예외 복구를 할 수 있는 상황에서는 checked 예외를 사용하자. checked 예외를 던지면 그 메소드 호출자가 catch 문에서 예외를 처리하거나 또는 외부로 넘겨야 한다. API 사용자가 checked 예외와 만났다는 것은, 그런 상황을 복구하라는 지시를 그 API 설계자로부터 받은 것이다. - unchecked exception 인 runtime exception 과 error 는 catch 할 필요가 없고, 일반적으로 catch 해서도 안 된.. 2017. 2. 21.
[Effective Java] 예외 상황에서만 예외를 사용하자. [Effective Java] 예외 상황에서만 예외를 사용하자. - 예외는 예외 상황을 대비해 설계된 것이므로, JVM 을 만드는 회사가 예외 처리 속도를 빠르게 하려고(우리가 명시적으로 검사하는 것만큼) 매달릴만한 일이 아니다. try-catch 블록 내부에 코드를 넣으면, 여러 종류의 JVM 이 해 줄 수 있는 나름의 최적화를 못하게 하는 부작용이 생길 수 있다. 배열을 반복 루프 처리하면서 정상적인 루프 종료 검사를 하는 표준 이디엄 코드가 반드시 중복 검사를 하는 것은 아니다. 근래의 JVM들에서는 그런 코드를 최적화한다. - 예외는 예외적인 상황에서만 사용해야 한다. 절대로 정상적인 흐름 제어에 사용하면 안된다. - 잘 설계된 API에서는 클라이언트가 예외를 사용해서 정상적인 흐름 제어를 하게끔.. 2017. 2. 20.
[Effective Java] 보편화된 작명 규칙을 따르자. [Effective Java] 보편화된 작명 규칙을 따르자. - 패키지 이름은 짧게 하되, 일반적으로 9자 이내의 문자가 좋다. awt와 같이 복합 단어의 첫 자를 딴 두문자나, util 과 같은 약어를 사용해도 좋다. - 타입 매개변수의 이름은 통상적으로 단일 문자이며, 대부분 다음 다섯 개 중 하나이다. 임의 타입은 T, 컬렉션 요소 타입은 E, Map 의 키와 값은 K, V, 예외는 X 임의 타입의 순차는 T에 이어 U, V 또는 T1, T2, T3 등과 같이 하기도 한다. - boolean 이 아닌 속성을 반환하는 메소드의 이름은 명사, 명사구, 또는 동사인 get 으로 시작하는 동사구로 구성한다. size, hashCode, getTime 등이 그 예이다. 이런 return 값이 있는 메소드들은.. 2017. 2. 17.
[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] 객체 참조는 그 객체의 인터페이스 타입으로 하자 - 객체를 참조할 때는 클래스보다는 인터페이스를 사용해야 한다. 만일 적합한 인터페이스 타입이 있다면, 매개 변수, 반환 값, 변수, 필드 모두 다 인터페이스 타입을 사용해서 선언해야 한다. 유일하게 객체의 클래스를 참조할 필요가 있는 경우는 생성자에서 객체를 생성할 때이다. - 인터페이스를 객체의 타입으로 사용하는 습관을 들이면, 프로그램이 훨씬 더 유연해진다. - 인터페이스의 구현체(클래스)를 변경하고자 하는 이유는, 새로 변경한 구현체가 더 좋은 성능을 내는 경우가 많다. - 만일 적합한 인터페이스가 없다면, 객체를 참조하는 타입을 인터페이스 대신 클래스로 하는 수밖에 없다. 적합한 인터페이스가 없는 경우는 보통 fina.. 2017. 2. 9.
[Effective Java] 문자열 결합의 성능 저하를 주의하자. [Effective Java] 문자열 결합의 성능 저하를 주의하자. - 문자열 결합 연산자(+)는 편리하지만 크기 조정이 안 된다는 단점이 있다. 문자열 결합 연산자를 n개의 문자열에 반복적으로 사용하면 n의 제곱에 비례하는 시간이 소요된다. String 이 불변(immutable)이기 때문이다. - 원하는 성능을 얻으려면 String 대신 StringBuilder 를 사용하자. - StringBuilder 를 결과를 충분히 저장할 만큼의 크기로 만들면 성능에 더 유리하다. 미리 산정된 만큼의 크기로 StringBuilder 를 생성하지 않고, 기본 크기로 생성해도 + 형태보다 여전히 50배 이상 빠르다. - StringBuilder 를 사용하기 싫다면 문자 타입을 저장하는 배열을 사용하거나, 문자열을 .. 2017. 2. 7.
반응형