혜성처럼 빛나는 정보

개발을 하면서 자바 최적화까지 신경 쓰면서 완벽하게 개발이 되면 좋겠지만, 대부분은 그렇지 않다. 이번에는 자바 최적화에 관련해서 알아보자.

아주 예전의 프로그래머들의 최적화에 대한 이야기를 들어보면, 다음과 같다. "효율성이라는 이름 아래 행해진 컴퓨틴 죄악이 더 많다", 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원", "최적화를 할 때는 다음 규칙을 따르자. 첫 번째는 하지 마라이고 두 번째는 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라" 위와 같은 이야기들은 최적화의 어두운 진실을 이야기해 준다. 최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇게 된다. 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 탄생시키는 것이다. 성능 때문에 견고한 구조를 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하자. 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 안내해 줄 것이다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다. 프로그램을 완성할 때까지 성능 문제를 무시하라는 뜻이 아니다. 구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다. 완성된 설계의 기본 틀을 변경하려다 보면 유지보수하거나 개선하기 어려운 꼬인 구조의 시스템이 만들어지기 쉽기 때문이다. 따라서 설계 단계에서 성능을 반드시 염두에 두어야 한다. 성능을 제한하는 설계를 피하라. 완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다. API 네트워크 프로토콜, 영구 저장용 데이터 포맷 등이 대표적이다. 이런 설계 요소들은 완성 후에는 변경하기 어렵거나 불가능할 수 있으며, 동시에 시스템 성능을 심각하게 제한할 수 있다. API를 설계할 때 성능에 주는 영향을 고려하라. public 타입을 가변으로 만들면, 즉 내부 데이터를 변경할 수 있게 만들면 불필요한 방어적 복사를 수없이 유발할 수 있다. 비슷하게, 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지도 물려받게 된다. 인터페이스도 있는데 굳이 구현 타입을 사용하는 것 역시 좋지 않다. 특정 구현체에 종속되게 하여, 나중에 더 빠른 구현체가 나오더라도 이용하지 못하게 된다. API 설계가 성능에 주는 영향은 현실적인 문제다. java.awt.Component 클래스의 getSize 메서드를 생각해 보자. 이 API 설계자는 이 메서드가 Dimension 인터페이스를 반환하도록 결정했다. 여기에 더해 Dimension은 가변으로 설계했으니 getSize를 호출하는 모든 곳에서 Dimension 인스턴스를 새로 생성해야만 한다. 요즘 VM이라면 이런 작은 객체를 몇 개 생성하는 게 큰 부담이 아니지만, 수백만 개를 생성해야 한다면 이야기가 달라진다. 이 API를 다르게 설계했을 수도 있다. Dimension을 불변으로 만드는 게 가장 이상적이지만, getSize를 getWidth와 getHeight로 나누는 방법도 있다. 즉, Dimension 객체의 기본 타입 값들을 따로따로 반환하는 방식이다. 실제로도 자바 2에서는 성능 문제를 해결하고자 Component 클래스에 이 메서드들을 추가했다. 하지만 기존 클라이언트 코드는 여전히 getSize 메서드를 호출하며 원래 내렸던 API 설계 결정의 폐해를 감내하고 있다. 다행히 잘 설계된 API는 성능도 좋은 게 보통이다. 그러니 성능을 위해 API를 왜곡하는 건 매우 안 좋은 생각이다. API를 왜곡하도록 만든 그 성능 문제는 해당 플랫폼이나 아랫단 소프트웨어의 다음 버전에서 사라질 수도 있지만, 왜곡된 API와 이를 지원하는 데 따르는 고통은 영원히 계속될 것이다. 신중하게 설계하여 깨끗하고 명확하고 멋진 구조를 갖춘 프로그램을 완성한 다음에야 최적화를 고려해 볼 차례가 된다. 물론 성능에 만족하지 못할 경우에 한정된다. 최적화 규칙에 한 가지를 추가해 보자. "각각의 최적화 시도 전후로 성능을 측정하라" 정도가 되겠다. 아마도 측정 결과에 놀랄 때가 많을 것이다. 시도한 최적화 기법이 성능을 눈에 띄게 높이지 못하는 경우가 많고, 심지어 더 나빠지게 할 때도 있다. 주요 원인은 프로그램에서 시간을 잡아먹는 부분을 추측하기가 어렵기 때문이다. 느릴 거라고 짐작한 부분이 사실은 성능에 별다른 영향을 주지 않는 곳이라면 시간만 허비한 꼴이 된다. 일반적으로 90%의 시간을 단 10%의 코드에서 사용한다는 사실을 기억해 두자. 프로파일링 도구는 최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다. 이런 도구는 개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공하여, 집중할 곳은 물론 알고리즘을 변경해야 한다는 사실을 알려주기도 한다. 프로그램에 시간이 거듭제곱으로 증가하는 알고리즘이 숨어 있다면 더 효율적인 것으로 교체해야 한다. 그러면 다른 튜닝을 하지 않아도 문제가 사라질 것이다. 시스템 규모가 커질수록 프로파일러가 더 중요해진다. 건초더미에서 바늘 찾기와 비슷하다. 건초더미가 거대해질수록 금속탐지기가 더 절실해진다. 그 외에 jmh도 언급해 둘 만한 도구이다. 프로파일러는 아니지만 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤치마킹 프레임워크다. 최적화 시도 전후의 성능 측정은 C와 C++ 같은 전통적인 언어에서도 중요하지만, 성능 모델이 덜 정교한 자바에서는 중요성이 더욱 크다. 자바는 다양한 기본 연산에 드는 상대적인 비용을 덜 명확하게 정의하고 있다. 다시 말해, 프로그래머가 작성하는 코드와 CPU에서 수행하는 명령 사이의 추상화 격차가 커서 최적화로 인한 성능 변화를 일정하게 예측하기가 그만큼 더 어렵다. 그래서인지 최적화가 관련해 일부만 맞거나 터무니없는 미신들이 떠돌아다닌다. 

요약하자면,

빠른 프로그램을 작성하려 안달 내지 말자. 좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다. 하지만 시스템을 설계할 때, 특히 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷을 설계할 때는 성능을 염두에 두어야 한다. 시스템 구현을 완료했다면 이제 성능을 측정해 보라. 충분히 빠르면 그것으로 끝이다. 그렇지 않다면 프로파일러를 사용해 문제의 원인이 되는 지점을 찾아 최적화를 수행하자. 가장 먼저 어떤 알고리즘을 사용했는지를 살펴보자. 알고리즘을 잘못 골랐다면 다른 저수준 최적화는 아무리 해봐야 소용이 없다. 만족할 때까지 이 과정을 반복하고, 모든 변경 후에는 성능을 측정하자.

개발을 하다보면 이름을 짓는것은 항상 고민되는 문제이다. 이 문제를 해결하기 위해 명명 규칙에 대해 공부해보자.

자바의 명명 규칙은 자바 언어 명세에 잘 기술되어 있다. 크게 철자와 문법, 두 범주로 나뉜다. 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 이 규칙들은 특별한 이유가 없는 한 반드시 따라야 한다. 이 규칙을 어긴 API는 사용하기 어렵고, 유지보수하기 어렵다. 철자 규칙이나 문법 규칙을 어기면 다른 프로그래머들이 그 코드를 읽기 번거로울 뿐 아니라 다른 뜻으로 오해할 수도 있고 그로 인해 오류까지 발생할 수 있다. 패키지와 모듈 이름은 각 요소를 점으로 구분하여 계층적으로 짓는다. 요소들은 모두 소문자 알파벳 혹은 숫자로 이뤄진다. 내부조직이 아닌 바깥에서도 사용될 패키지라면 조직의 인터넷 도메인 이름을 역순으로 사용한다. 예외적으로 표준 라이브러리와 선택적 패키지들은 각각 java와 javax로 시작한다. 도메인 이름을 패키지 이름의 접두어로 변환하는 자세한 규칙은 자바 언어 명세에 적혀 있다. 패키지 이름의 나머지는 해당 패키지를 설명하는 하나 이상의 요소로 이뤄진다. 각 요소는 일반적으로 8자 이하의 짧은 단어로 한다. utiliites보다는 util처럼 의미가 통하는 약어를 추천한다. 여러 단어로 구성된 이름이라면 awt처럼 각 단어의 첫 글자만 따서 써도 좋다. 요소의 이름은 보통 한 단어 혹은 약어로 이뤄진다. 인터넷 도메인 이름 뒤에 요소 하나만 붙인 패키지가 많지만, 많은 기능을 제공하는 경우엔 계층을 나눠 더 많은 요소로 구성해도 좋다. 예를 들어, java.util은 java.util.concurrent.atomic과 같이 그 밑에 수많은 패키지를 가지고 있다. 자바가 패키지 계층에 관해 언어 차원에서 지원하는 건 거의 없지만, 어쨌든 이처럼 하부의 패키지를 하위 패키지라 부른다. 클래스와 인터페이스의 이름은 하나 이상의 단어로 이뤄지며, 각 단어는 대문자로 시작한다. 여러 단어의 첫 글자만 딴 약자나 max, min처럼 널리 통용되는 줄임말을 제외하고는 단어를 줄여 쓰지 않도록 한다. 약자의 경우 첫 글자만 대문자로 할지 전체를 대문자로 할지는 살짝 논란이 있다. 전체를 대문자로 쓰는 프로그래머도 있지만, 그래도 첫 글자만 대문자로 하는 쪽이 훨씬 많다. HttpUrl처럼 여러 약자가 혼합된 경우라도 각 약자의 시작과 끝을 명확히 알 수 있기 때문이다. 메서드와 필드 이름은 첫 글자를 소문자로 쓴다는 점만 빼면 클래스 명명 규칙과 같다. 첫 단어가 약자라면 단어 전체가 소문자여야 한다. 단 상수 필드는 예외다. 상수 필드를 구성하는 단어는 모두 대문자로 쓰며 단어 사이는 밑줄로 구분한다. 상수 필드는 값이 불변인 static final 필드를 말한다. 달리 말하면 static final 필드의 타입이 기본 타입이나 불변 참조 타입이라면 상수 필드에 해당한다. static final 필드이면서 가리키는 객체가 불변이라면 비록 그 타입은 가변이라도 상수 필드다. 이름에 밑줄을 사용하는 요소로는 상수 필드가 유일하다는 사실도 기억해두자. 지역변수에도 다른 멤버와 비슷한 명명 규칙이 적용된다. 단, 약어를 써도 좋다. 약어를 써도 그 변수가 사용되는 문맥에서 의미를 쉽게 유추할 수 있기 떄문이다. 입력 매개변수도 지역변수의 하나다. 하지만 메서드 설명 문서에까지 등장하는 만큼 일반 지역변수보다는 신경을 써야 한다. 타입 매개변수 이름은 보통 한 문자로 표현한다. 대부분은 다음의 다섯 가지 중 하나다. 임의의 타입엔 T를, 컬렉션 원소의 타입은 E를, 맵의 키와 값에는 K와 V를 예외에는 X를 메서드의 반환 타입에는 R을 사용한다. 그 외에 임의 타입의 시퀀스에는 T, U, V 혹은 T1, T2, T3를 사용한다.

문법 규칙은 철자 규칙과 비교하면 더 유연하고 논란도 많다. 패키지에 대한 규칙은 따로 없다. 객체를 생성할 수 있는 클래스의 이름은 보통 단수 명사나 명사구를 사용한다. 객체를 생성할 수 없는 클래스의 이름은 보통 복수형 명사로 짓는다. 인터페이스 이름은 클래스와 똑같이 짓거나 able 혹은 ible로 끝나는 형용사로 짓는다. 애너테이션은 워낙 다양하게 활용되어 지배적인 규칙이 없이 명사, 동사, 전치사, 형용사가 두루 쓰인다. 어떤 동작을 수행하는 메서드의 이름은 동사나 동사구로 짓는다. boolean 값을 반환하는 메서드라면 보통 is나 has로 시작하고 명사나 명사구, 혹은 형용사로 기능하는 아무 단어나 구로 끝나도록 짓는다. 반환 타입이 boolean이 아니거나 해당 인스턴스의 속성을 반환하는 메서드의 이름은 보통 명사, 명사구, 혹은 get으로 시작하는 동사구로 짓는다. 세 번째 형식, 즉 get으로 시작하는 형태만 써야 한다는 주장도 있지만, 근거가 빈약하다. 보통은 처음 두 형태를 사용한 코드의 가독성이 더 좋기 때문이다. get으로 시작하는 형태는 주로 자바빈즈 명세에 뿌리를 두고 있다. 자바빈즈는 재사용을 위한 컴포넌트 아키텍처의 초기 버전 중 하나로, 최근의 도구 중에도 이 명명 규칙을 따르는 경우가 제법 많다. 따라서 이런 도구와 어우러지는 코드를 작성한다면 이 규칙을 따라도 상관없다. 한편 클래스가 한 속성의 게터와 세터를 모두 제공할 때도 적합한 규칙이다. 이런 경우라면 보통 getAttribute와 setAttribute 형태의 이름을 갖게 될 것이다. 꼭 언급해둬야 할 특별한 메서드 이름이 몇 가지 있다. 객체의 타입을 바꿔서, 다른 타입의 또 다른 객체를 반환하는 인스턴스 메서드의 이름은 보통 toType 형태로 짓는다. 객체의 내용을 다른 뷰로 보여주는 메서드의 이름은 asType 형태로 짓는다. 객체의 값을 기본 타입 값으로 반환하는 메서드의 이름은 보통 typeValue 형태로 짓는다. 마지막으로, 정적 팩터리의 이름은 다양하지만 from, of, valueOf, instance, getInstance, newInstance, getType, newType을 흔히 사용한다. 필드 이름에 관한 문법 규칙은 클래스, 인터페이스, 메서드 이름에 비해 덜 명확하고 덜 중요하다. API 설계를 잘 했다면 필드가 직접 노출될 일이 거의 없기 때문이다. boolean 타입의 필드 이름은 보통 boolean 접근자 메서드에서 앞 단어를 뺀 형태다. 다른 타입의 필드라면 명사나 명사구를 사용한다. 지역변수 이름도 필드와 비슷하게 지으면 되나, 조금 더 느슨하다.

요약하자면,

표준 명명 규칙을 체화하여 자연스럽게 베어 나오도록 하자. 철자 규칙은 직관적이라 모호한 부분이 적은데 반해, 문법 규칙은 더 복잡하고 느슨하다. 자바 언어 명세의 말을 인용하자면 오랫동안 따라온 규칙과 충돌한다면 그 규칙을 맹종해서는 안된다라고 한다. 상식이 이끄는 대로 따르자.

자바에서 문자열은 가장 많이 쓰이는 타입 중 하나가 아닐까 싶다. 그만큼 적절하게 사용하는 방법을 알아 둔다면 큰 도움이 될 수 있다. 이번에는 어떠한 경우에 문자열 사용을 피해야 하는지와 문자열 연결에서 주의해야 할 점을 알아보자.

문자열은 다른 값 타입을 대신하기에 적합하지 않다. 많은 사람이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용한다. 자연스러워 보이지만, 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는 게 좋다. 받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다. 예나 아니요 같은 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 한다. 일반화해 이야기하자면 기본 타입이든 참조 타입이든 적절한 값 타입이 있다면 그것을 사용하고 없다면 새로 하나 작성하자. 의외로 지켜지지 않는 경우가 많다. 문자열은 열거 타입을 대신하기에 적합하지 않다. 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 낫다. 문자열은 혼합 타입을 대신하기에 적합하지 않다. 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않은 생각이다. 예를 들어 "String compoundKey = className + "#" + i.next();" 와 같은 방식은 단점이 많은 방식이다. 혹여라도 두 요소를 구분해주는 문자 #이 두 요소 중 하나에서 쓰였다면 혼란스러운 결과를 초래한다. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다. 적절한 equals, toString, compareTo 메서드를 제공할 수 없으며, String이 제공하는 기능에만 의존해야 한다. 그래서 차라리 전용 클래스를 새로 만드는 편이 낫다. 이런 클래스는 보통 private 정적 멤버 클래스로 선언한다. 문자열은 권한을 표현하기에 적합하지 않다. 권한을 문자열로 표현하는 경우가 종종 있다. 예를 들어 스레드 지역변수 기능을 설계한다고 해보자. 그 이름처럼 각 스레드가 자신만의 변수를 갖게 해주는 기능이다. 자바가 이 기능을 지원하기 시작한 때는 자바 2부터로, 그전에는 프로그래머가 직접 구현해야 했다. 그 당시 이 기능을 설계해야 했던 여러 프로그래머가 독립적으로 방법을 모색하다가 종국에는 똑같은 설계에 이르렀다. 바로 클라이언트가 제공한 문자열 키로 스레드별 지역변수를 식별한 것이다. 이 방식의 문제는 스레드 구분용 문자열 키가 전역 이름공간에서 공유된다는 점이다. 이 방식이 의도대로 동작하려면 각 클라이언트가 고유한 키를 제공해야 한다. 그런데 만약 두 클라이언트가 서로 소통하지 못해 같은 키를 쓰기로 결정한다면, 의도치 않게 같은 변수를 공유하게 된다. 결국 두 클라이언트 모두 제대로 기능하지 못할 것이다. 보안도 취약하다. 악의적인 클라이언트라면 의도적으로 같은 키를 사용하여 다른 클라이언트의 값을 가져올 수도 있다. 이 API는 문자열 대신 위조할 수 없는 키를 사용하면 해결된다. 이 키를 권한이라고도 한다. 이렇게 키를 사용하는 방법은 문자열 기반 API의 문제 두 가지를 모두 해결해주지만, 개선할 여지가 있다. 고민해보자. 

문자열에 대한 또 다른 이야기를 해보자. 자주 사용하는 문자열 연산에 관한 이야기이다. 문자열 연결 연산자(+)는 여러 문자열을 하나로 합쳐주는 편리한 수단이다. 그런데 한 줄짜리 출력값 혹은 작고 크기가 고정된 객체의 문자열 표현을 만들 때라면 괜찮지만, 본격적으로 사용하기 시작하면 성능 저하를 감내하기 어렵다. 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n 제곱에 비례한다. 문자열은 불변이라서 두 문자열을 연결할 경우 양쪽의 내용을 모두 복사해야 하므로 성능 저하는 피할 수 없는 결과다. 예를 들어 다음 메서드는 청구서의 품목을 전부 하나의 문자열로 연결해준다.

public String statement() {
	String result = "";
	for (int i = 0; i < numItems(); i++)
		result += lineForItem(i);
	return result;
}

품목이 많을 경우 이 메서드는 심각하게 느려질 수 있다. 성능을 포기하고 싶지 않다면 String 대신 StringBuilder를 사용하자.

public String statementWithStringBuilder() {
	StringBuilder sb = new StringBuilder(numItems() * LINE_WIDTH);
	for (int i = 0; i < numItems(); i++)
		sb.append(lineForItem(i));
	return sb.toString();
}

자바 6 이후 문자열 연결 성능을 다방면으로 개선했지만, 이 두 메서드의 성능 차이는 여전히 크다. 품목을 100개로 하고 lineForItem이 길이 80인 문자열을 반환하게 하여 테스트해보니 StringBuilder를 사용했을 때가 6.5배나 빨랐다. statement 메서드의 수행 시간은 품목 수의 제곱이 비례해 늘어나고 StringBuilder를 사용했을 경우는 선형으로 늘어나므로, 품목 수가 늘어날수록 성능 격차도 점점 벌어질 것이다. StringBuilder를 사용한 예제에서 StringBuilder를 선언할 때, 전체 결과를 담기에 충분한 크기로 초기화한 점을 잊지 말자. 하지만 기본값을 사용하더라도 여전히 5.5배나 빠르다.

요약하자면,

더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면, 문자열을 쓰고 싶은 유혹을 뿌리치자. 또한 문자열 연결에 대한 원칙은 간단하다. 성능에 신경 써야 한다면 많은 문자열을 연결할 때는 문자열 연결 연산자(+)를 피하자. 대신 StringBuilder의 append 메서드를 사용하라. 문자 배열을 사용하거나 문자열을 연결하지 않고 하나씩 처리하는 방법도 있다.

자바를 사용하면서 primitive타입과 primitive타입에 대응하는 래핑된 object 타입 중 어떤 것을 선택할지는 간단해 보이지만, 중요한 문제이다. 기본적으로 성능을 생각하면 heap 영역에 영향이 없는 primitive 타입을 선택하지만, 어쩔 수 없이 (없는 값의 기본을 null로 해야 명세에 부합하여 사이드 이펙트가 없을 때) 래퍼 클래스를 사용하는 경우도 있었다. 이번에는 이 부분에 대해 더 자세히 알아보자.

자바에서는 int, double, boolean과 같은 기본 타입에 대응하는 박싱된 기본 타입 (Integer, Double, Boolean 등) 들이 있다. 오토박싱과 오토언박싱 덕분에 두 타입을 크게 구분하지 않고 사용할 수는 있지만, 차이가 사라지는 것은 아니다. 둘 사이에는 분명한 차이가 있으니 어떤 타입을 사용하는지는 상당히 중요하다. 주의해서 선택해야 한다는 말이다. 기본 타입과 박싱된 기본 타입의 주된 차이는 크게 세 가지다. 첫 번째, 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 값에 더해 식별성이란 속성을 갖는다. 달리 말하면 박싱된 기본 타입의 두 인스턴스는 값이 같아도 서로 다르다고 식별될 수 있다. 두 번째, 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입은 유효하지 않은 값, 즉 null을 가질 수 있다. 세 번째, 기본 타입이 박싱된 기본 타입보다 시간과 메모리 사용 면에서 더 효율적이다. 이상의 세 가지 차이 때문에 주의하지 않고 사용하면 진짜로 문제가 발생할 수 있다. Integer값을 오름차순으로 정렬하는 비교자를 보자. Integer는 그 자체로 순서가 있으니 이 비교자가 실질적인 의미는 없지만, 흥미로운 점을 하나 보여준다.

Comparator<Integer> naturalOrder = (i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);

별다른 문제를 찾기 어렵고, 실제로 이것저것 테스트해봐도 잘 통과한다. 예컨대 Collections.sort에 원소 백만 개짜리 리스트와 이 비교자를 넣어 돌려도 아무 문제가 없다. 리스트에 중복이 있어도 상관없다. 하지만 심각한 결함이 숨어 있으니 이 결함을 눈으로 확인하고 싶다면 naturalOrder.compare(new Integer(42), new Integer(42))의 값을 출력해보자. 두 Integer 인스턴스의 값이 42로 같으므로 0을 출력해야 하지만, 실제로는 1을 출력한다. 즉, 첫 번째 Integer가 두 번째보다 크다고 주장한다. 원인이 뭘까? naturalOrder의 첫 번째 검사(i <j)는 잘 작동한다. 여기서 i와 j가 참조하는 오토박싱된 Integer 인스턴스는 기본 타입 값으로 변환된다. 그런 다음 첫 번째 정숫값이 두 번째 값보다 작은지를 평가한다. 만약 작지 않다면 두 번째 검사(i == j)가 이뤄진다. 그런데 이 두 번째 검사에서는 두 객체 참조의 식별성을 검사하게 된다. 비록 값은 같더라도 i와 j가 서로 다른 Integer 인스턴스라면 이 비교의 결과는 false가 되고, 비교자는 1을 반환한다. 즉, 첫 번째 Integer 값이 두 번째보다 크다는 것이다. 이처럼 박싱된 기본 타입에 == 연산자를 사용하면 오류가 일어난다. 실무에서 이와 같이 기본 타입을 다루는 비교자가 필요하다면 Comparator.naturalOrder()를 사용하자. 비교자를 직접 만들면 비교자 생성 메서드나 기본 타입을 받는 정적 compare 메서드를 사용해야 한다. 그렇더라도 이 문제를 고치려면 지역변수 2개를 두어 각각 박싱된 Integer 매개변수의 값을 기본 타입 정수로 저장한 다음, 모든 비교를 이 기본 타입 변수로 수행해야 한다. 이렇게 하면 오류의 원인인 식별성 검사가 이뤄지지 않는다.

Comparator<Integer> naturalOrder = (iBoxed, jBoxed) -> {
	int i = iBoxed, j = jBoxed;
	return i < j ? -1 : (i == j ? 0 : 1);
};

Integer와 int를 비교할때를 보면, 거의 예외 없이 기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 박싱된 기본 타입의 박싱이 자동으로 풀린다. 그리고 null 참조를 언박싱하면 NullPointerException이 발생한다. 이 예에서 보듯, 이런 일은 어디서든 벌어 질 수 있다. 해법은 i를 int로 바꿔주면 된다. 또한, 실수로 for문을 돌면서 더하는 연산을 할때, sum의 값을 박싱된 기본 타입으로 선언하면 박싱과 언박싱이 반복해서 일어나기 때문에, 치명적으로 느려지는것을 체감할 수 있다. 모든 문제의 원인은 하나다. 프로그래머가 기본 타입과 박싱된 기본 타입의 차이를 무시한 대가를 치른 것이다. 그렇다면 박싱된 기본 타입은 언제 써야 하는가? 적절히 쓰이는 경우가 몇 가지 있다. 첫 번째, 컬렉션의 원소, 키, 값으로 쓴다. 컬렉션은 기본 타입을 담을 수 없으므로 어쩔 수 없이 박싱된 기본 타입을 써야만 한다. 더 일반화해 말하면, 매개변수화 타입이나 매개변수화 메서드의 타입 매개변수로는 박싱된 기본 타입을 써야 한다. 자바 언어가 타입 매개변수로 기본 타입을 지원하지 않기 때문에다. 예컨대 변수를 ThreadLocal<int> 타입으로 선언하는 건 불가능하며, 대신 ThreadLocal<Integer>를 써야 한다. 마지막으로, 리플렉션을 통해 메서드를 호출할 때도 박싱된 기본 타입을 사용해야 한다.

요약하자면,

기본 타입과 박싱된 기본 타입 중 하나를 선택해야 한다면 가능하면 기본 타입을 사용하라. 기본 타입은 간단하고 빠르다. 박싱된 기본 타입을 써야 한다면 주의를 기울이자. 오토박싱이 박싱된 기본 타입을 사용할 때의 번거로움을 줄여주지만, 그 위험까지 없애주지는 않는다. 두 박싱된 기본 타입을 == 연산자로 비교한다면 식별성 비교가 이뤄지는데, 이는 원한 게 아닐 가능성이 크다. 같은 연산에서 기본 타입과 박싱된 기본 타입을 혼용하면 언박싱이 이뤄지며, 언박싱 과정에서 NullPointerException을 던질 수 있다. 마지막으로, 기본 타입을 박싱하는 작업은 필요 없는 객체를 생성하는 부작용을 낳을 수 있다.

출처: 이펙티브 자바 3판