재미로 보는 자바 컬렉션 프레임 워크의 초기 역사, 코틀린 자료형 비교

자바 알고리즘 인터뷰 책을 보며 학습한 내용

 

// 예시

List<Integer> a = new ArrayList<>();
// 삽입 시 add() 사용
a.add(1);
a.add(2);
a.add(3);

Set<Integer> b = new HashSet<>();
// 삽입, add() 로 동일
b.add(1);
b.add(2);
b.add(3);

Map<Integer> c = new HashMap<>();
// 삽입 시 put() 사용, 키/값 형태로 데이터 추가
c.put("a", 1);
c.put("b", 2);

 

초기 자료형의 성능 문제

 자바는 1.0 정식 버전을 출시하던 초기 시절부터 목록형 자료형에 대한 고민이 있었다. 자바 컬렉션 프레임워크가 등장한 것은 그로부터 2년이나 더 지난 후였고, 그 전에는 C++의 영향을 받아 벡터 형태의 자료형과 해시 테이블 형태의 자료형을 별도로 제공했다. 그것이 바로 Vector와 Hashtable이다. 두 자료형의 가장 큰 문제는 성능이 떨어진다는 점이다. 자바 초기 시절에는 동기화(Synchronized)를 과도하게 적용하곤 했다. 아직 CPU 코어가 1개이던 시절이었고, 파이썬 같은 언어는 애초에 언어 전체가 단일 동기화 시스템에 의존할 정도였으니(파이썬은 지금도 이 같은 특징으로 인해 멀티 스레딩에 어려움을 겪고 있다) 특별히 문제될 일은 없었다. 그러나 멀티 코어 시대가 열리면서 더 이상 동기화를 디폴트로 둘 수 없었다. 하지만 기존 자료형도 하위 호환성을 위해 함부로 수정할 수 없었다. 이에 따라 완전히 새로운 자료형을 디자인하게 됐다. Vector는 List와 그 구현 클래스로, Hashtable은 Map 인터페이스와 그 구현 클래스로 대체됐다. 자료형뿐만 아니라 문자열을 조작하는 클래스도 같은 이유로 대체됐다. StringBuffer는 모든 메소드가 동기화로 동작해 개선이 필요했지만 마찬가지로 하위 호환성을 위해 수정할 수 없었고, StgringBuilder로 대체됐다.

 

코틀린은 어떤 자료형을 제공할까?

 Byte, Short, Int, Long, Float, Double, Boolean, Char 코틀린의 자료형은 자바와 별반 다르지 않다. 하지만 코틀린은 자바처럼 완전한 원시형은 제공하지 않는다. 또한 코틀린은 변수를 선언할 때 자료형 선언을 생략할 수 있는데, 이때 코틀린은 타입 추론(Type Inference)을 진행하여 어떤 자료형인지 자동으로 판단한다.

 

코틀린 자료형의 속도는 과연 빠를까

 코틀린의 Int는 자바의 원시형 int를 한 꺼풀 감싼 형태로 저장한다. Long, Byte도 마찬가지다.

// IntArray에 1억개 데이터 삽입
val intElements = IntArray(100000000) // 1억개의 요소
for (i in 0 until 100000000 - 1) intElements[i] = 1
intElements[100000000 -1] = 2 // 마지막 요소의 값은 2

// IntArray 1억개 중 값이 2인것을 찾기
var index = 0
while(2 != intElements[index]) index++

삽입: 116밀리초, 찾기: 25밀리초 자바에서 원시형의 데이터 타입을 이용해 처리했을 때와 거의 동일한 시간이 걸린다. 코틀린은 참조형을 제공하지만 실제로는 자바의 원시형을 감싼 형태이다. IntArray는 Java int[] 와 동일하다.