[JAVA] Java의 역사와 JVM, 알아두어야 하는 상식

출처 : 자바의 神 VOL.1 기초 문법편

■ 자바의 역사

자바의 역사는 1991년으로 거슬러 올라간다. 1991년에 "Green"이라는 프로젝트가 생기면서 자바의 모태가 탄생하기 시작했다.

제임스 고스링(James Gosling), 마이크 쉐리든(Mike Sheridan), 패트릭 노튼(Patrick Naughton) 이렇게 3명의 젊은이가

TV와 시청자가 서로 상호 작용을 하는(interactive 한) 것을 만들기 위해서 시작되었다.

지금은 IPTV와 같은 것이 대중화 되어 있지만, 그때만 해도 너무 앞서가는 것이었다.

1992년 고슬링의 사무실 앞에 있는 참나무를 보고 이름을 지은 "Oak"라는 언어다.

그 이후에 1995년 "Oak"라는 언어의 이름이 커피의 한 종류를 뜻하는 "자바 커피"의 이름을 본따 "Java"라고 바뀌면서 자바 기술이 시작하게 되었다.

1995년에 자바 언어를 만들면서 "Write Once, Run Anywhere(WORA)"라는 모토가 만들어졌으며,

여러 플랫폼에서 수행할 수 있는 개발 언어를 목표로 개발되었다.

1996년에 드디어 JDK 1.0이 출시되었으며, 그 이듬해 1997년에 출시한 JDK 1.1DMS 3주만에 22만 다운로드를 기록하면서 폭발적인 성장을 예견하게 되었다.

여기서 JDK라는 단어는 Java Development Kit의 약자다.

1998년 12월 J2SE라는 이름으로 자바의 기본 버전 명칭이 바뀌면서 J2SE 1.2가 출시되었다.

참고로 J2SE는 Java 2 Standard Edition의 약자이며 기존의 JDK를 의미하는 것이다.

왜 이렇게 이름이 바뀌었냐면, 기업 등에서 만드는 시스템을 개발하기 위한 J2EE라는 Enterprise Edition과

블랙베리와 같은 전화기에서 아직도 사용하고 있는 J2ME라는 Micro Edition과 혼동을 막기 위함이었다.

그 이후에 2000년 J2SE 1.3이, 우리나라에서 월드컵이 열린 2002년 J2SE 1.4가 출시되었다. 그리고 2004년 J2SE 5가 출시되었다.

J2SE 1.4 버전까지만 해도 버전 이름이 1.1 ~ 1.4까지 증가하였지만, J2SE 1.5 버전부터는 앞의 1.을 뺀 J2SE 5라고 불리게 되었다.

그 다음에 약간의 개선이 이루어진 Java SE 6가 2006년 출시되었다.

그리고, 2011년 오랜 기간동안의 업그레이드 준비를 마친 Java SE 7이 탄생되었다.

Java SE 6까지는 이제는 역사속으로 사라진 Sun Microsystems라는 회사에서

자바에 대한 주요 스팩을 만들고 Java를 만들어 왔지만, Java SE 7 부터는 Oracle이라는 회사가

Sun Microsystems를 인수하여 지금에 이르고 있다.

※ 자바의 표준 버전의 이름이 JDK, J2SE, Java SE로 변경되어 왔지만 일반적으로 JDK라고 통일하여 불리고 있다.

---

■ JDK, J2SE, Java SE 외에 자바에서 사용되는 다른 용어

앞서 설명한 각각의 용어는 다음의 약자다.

   ● JDK : Java Development Kit

   ● J2SE : Java 2 Standard Edition

   ● Java SE : Java Standard Edition

여기서 Java 2에서 빠진 것은 Java SE 6가 출시되면서 부터이며,

이렇게 빠진 이유는 마케팅을 위해서라기 보다 쉽게 자바를 부를 수 있도록 Java로 통칭했다고 한다.

그리고, 자바를 개발하기 위해서 설치를 하다 보면, JDK와 JRE로 분리되어 있는 것을 알고 있을 것이다.

여기서 각각의 용어는 다음을 의미한다.

   ● JDK : Java Development Kit

   ● JRE : Java Runtime Environment

각각의 이름에서 알 수 있듯이 JRE는 실행만을 위한 환경이다.

따라서, 이 JRE만 설치하면, 자바를 컴파일하는 등의 각종 프로그램이 제외된 상태로 설치된다.

가장 좌측을 보면 JDK와 JRE로 나뉘어져 있는 것을 볼 수 있다.

즉, JRE는 자바를 실행할 수 있는 환경의 집합이라고 보면 된다.

그리고, JRE에 있는 여러 가지 레고 블록처럼 칸칸이 쌓여 있는 것들은 자바에서 제공하는 라이브러리들이라고 보면 된다.

---

■ 자바 언어의 다섯가지 특징

#01. 자바는 "단순하고, 객체지향이며, 친숙"해야 한다.

지금 자바를 배우는 사람들은 자바가 단순하지 않은 언어라는 것을 알고 있다.

왜냐하면 수 많은 프레임웍들이 있고, 여러 관련된 사항들을 알아야 프로그램을 작성할 수 있기 때문이다.

(여기서 이야기 하는 단순한 이란 자바에 대한 기본 컨셉을 배우는 것이 어렵지 않다는 것을 의미한다.)

자바는 처음 만들 때부터 객체지향으로 디자인되어 있다.

그리고, 다형성, 캡슐화등 객체지향 언어의 특징들을 지원할 수 있는 구조로 되어 있다.

그리고 다형성, 캡슐화 등 객체지향 언어의 특징을 지원할 수 있는 구조로 되어 있다.

물론 개발하는 사람이 객체지향 프로그램을 작성하지 않으면 이러한 이점은 모두 사라진다.

다시 말해서, 자바를 쓴다고 해서 무조건 객체지향적으로 개발된다는 것은 아니다.

그리고, 자바로 개발할 때에는 처음부터 모든 것을 만들 필요가 없다.

개발하면서 필요한 여러 기능들은 이미 API를 통해제 제공하고 있다.

파일을 읽고 쓰거나 네트워크로 데이터를 주고 받는 I/O, 그래픽, UI등을 개발하기 위한 여러 라이브러리를 통해서

보다 쉽게 개발할 수 있는 환경을 제공한다.

#02. 자바는 "견고하며, 보안상 안전"하다.

자바는 컴파일 할 때와 실행할 때 문법적 오류에 대한 체크를 한다.

메모리 관리 모델이 매우 단순하고, C를 배우고 사용하는 개발자들의 머리를 아프게 하는 포인터의 개념이 없다.

이러한 특징들은 자바를 매우 믿을 수 있고, 견고한 소프트웨어가 될 수 있도록 도와준다.

자바는 기본적으로 분산 환경에서 사용하기 위해서 디자인 되었다.

분산 환경에서 보안은 매우 주용한 부분 중 하나다.

자바 기술은 외부에서 침입이 불가능한 애플리케이션을 만들 수 있도록 해준다.

네트워크 환경에서 클라이언트로 다운로드한 승인받지 않은 프로그램은 실행할 수 없도록 되어 있다.

따라서 바이러스를 생성하거나 파일 시스템을 공격할 수가 없다.

#03. 자바는 "아키텍처에 중립적이어야 하며 포터블"해야 한다.

자바로 작성한 프로그램은 매우 다양한 하드웨어 아키텍처에서 수행 할 수 있도록 되어 있다.

따라서 자바는 아키텍처에 중립적인 바이코드를 생성한다.

따러서, 자바의 버전만 동일하다면, 동일한 프로그램은 어떤 플랫폼에서도 실행 할 수 있다.

아키텍처 중립적이라는 말은 포터블한 시스템의 일부분일 뿐이다.

그래서, 기본 데이터 타입의 크기를 지정해 놓고, 숫자 연산자에 대한 행위들을 정의해 두었다.

따라서, 여러분들이 만드는 프로그램은 어떤 플랫폼에서도 동일한 결과가 나오며,

하드웨어와 소프트웨어 아키텍처에 따른 데이터 타입의 호환성에 문제가 발생하지 않는다.

이러한 호환성과 포터블한 환경을 제공하는 것은 JVM 덕분이다.

#04. 자바는 "높은 성능"을 제공해야 한다.

성능은 항상 고려를 하는 부분이다.

자바는 실행환경에서 최대한의 성능을 낼 수 있도록 되어 있다.

게다가 자동화된 가비지 컬렉터는 낮은 우선순위의 쓰레드로 동작하기 때문에 보다 높은 성능을 낼 수 있다.

그리고, 보다 빠른 성능을 위해서 네이티브한 언어로 작성한 부분을 자바에서 사용할 수도 있도록 되어 있다.

(자바가 이 세상에서 제일 빠른 언어라는 말은 아니다.)

#05. 자바는 "인터프리트 언어이며, 쓰레드를 제공하고, 동적인 언어"이다.

자바 인터프리터는 자바 바이트코드를 어떤 장비에서도 수행할 수 있도록 해준다.

따라서, 기존에 사용하던 무거운 컴파일과 링크와 테스트 사이클을 거쳐야 하는 개발환경보다 빠른 환경을 구축할 수 있다.

자바는 멀티 쓰레드 환경을 제공하기 때문에, 동시에 여러 작업을 수행할 수 있다.

따라서, 사용자에게 매우 빠른 사용 환경을 제공한다.

자바 컴파일러는 컴파일시 매우 엄격한 정적인 점검을 수행한다.

그리고, 실행시에 동적으로 필요한 프로그램을 링크시킨다.

게다가 새로운 코드는 다양한 소스에서 요청에 의해서 연결될 수 있다.

지금까지 간단하게 자바 언어의 특징에 대해서 살표보았다.

이러한 특징들은 자바 개발 초기에 정해진 것으로, 약간은 지금의 상황과 다른 부분이 있다.

하지만, 이 내용간의 근간은 달라지지 않고 계속 유지되고 있으므로, 기억해 두면 좋을 것이다.

---

■ JIT(Just-In-Time) 컴파일러란?

JIT라는 것은, Just-In-Time의 약자다.

JIT를 사용하는 언어에는 Java와, .NET 등이 있다. 즉, 자바에서만 사용하는 개념이 아니다.

JIT를 좀더 쉬운 말로 하면 "동적 변환(Dynamic Translation)"이라고 보면 된다.

이러한 JIT라는 것을 만든 이유는 프로그램 실행을 보다 빠르게 하기 위해서이다.

명칭이 컴파일러이지만, 실행시에는 적용되는 기술이다.

역사적으로 보면, 컴퓨터 프로그램을 실행하는 방식은 두가지로 나눌 수 있다.

하나는 인터프리터(Interpret) 방식이며, 다른 하나는 정적(Static) 컴파일 방식이다.

인터프리터 방식은 프로그램을 실행할 때마다 컴퓨터가 알아 들을 수 있는 언어로 변환하는 작업을 수행한다.

따라서, 간편하기는 하지만 성능이 매우 느릴 수 밖에 없다.

정적 컴파일 방식은 실행하기 전에 컴퓨터가 알아 들을 수 있는 언어로 변환화는 작업을 미리 실행한다.

따라서, 변환 작업은 딱 한 번만 수행한다.

JIT는 이 두 가지 방식을 혼합한 것이라고 보면 된다.

변환 작업은 인터프리터에 의해서 지속적으로 수행되지만,

필요한 코드의 정보는 캐시에 담아두었다가(메모리에 올려두었다가) 재사용 하게 된다.

여기서 헷갈릴 수 있는 부분은 javac 명령어를 사용하여 컴파일을 하기때문에

그럼 자바는 정적 컴파일 방식 아닌가? 라고 생각 할 수 있는데

자바 프로그래밍 과정에서는 javac라는 명령어를 사용하여 컴파일을 하는 단계에서 만들어진

class라는 파일은 바이트코드(ByteCode)일 뿐이다.

자바의 모토 중에 하나가 "Compile once, Run anywhere"다.

한번 컴파일한 코드로  Linux, Mac OS X, Window 등에서 모두 사용할 수 있다.

다시 말해서, javac라는 명령어를 수행한다는 것은 텍스트로 만드 java파일을 어떤 OS에서도 수행될 수 있도록

바이트코드라는 파일로 만든 것뿐이다.

컴퓨터가 알아먹을 수 있도록 하려면 다시 변환 작업이 필요한데,

이 작업을 JIT 컴파일러에서 한다고 보면 된다.

위 그림에서 "JVM → 기계코드"로 변환되는 부분은 JIT에서 수행하는 것이다.

JIT를 사용하면 반복적으로 수행되는 코드는 매우 빠른 성능을 보인다는 장점이 있지만,

반대로 처음에 시작할 때에는 변환 단계를 거쳐야 하므로 성능이 느리다는 단점이 있다.

하지만, 최근들어 CPU 성능이 많이 좋아졌고, JDK의 성능 개선도 많이 이루어졌기 때문에 방금 이야기한 단점도 많이 개선되었다.

---

■ 자바를 배우면 꼭 알아야 하는 용어(JVM, GC)

일반적으로 자바를 설명할 때 많이 사용되는 용어들은 다음과 같은 것들이 있다.

   ● JVM : Java Virtual Machine (자바 가상 머신)

   ● GC : Garbage Collector (가비지 컬렉터)

JVM은 작성한 자바 프로그램이 수행되는 프로세스를 의미한다.

다시 말해서, java라는 명령어를 통해서 애플리케이션이 수행되면, 이 JVM 위에서 애플리케이션이 동작한다.

이 JVM에서 여러분들이 작성한 프로그램을 찾고 실행하는 일련의 작업이 진행된다.

자바의 기본 메모리 관리는 개발자가 하지 않아도 된다.

메모리 관리를 JVM이 알아서 하기 때문이다. 이때 JVM 내에서 메모리 관리를 해주는 것을 바로 "가비지 컬렉터"라고 부른다.

Garbage는 우리나라말로 "쓰레기"라는 의미이며, 사용하고 남아 있는 전혀 필요없는 객체들이 여기에 속한다.

아무리 가비지 컬렉터가 쓰레기를 알아서 청소한다고 하더라도, 메모리를 효율적으로 사용하도록 개발하는 것은 중요하다.

일반적으로 사용되는 GC라는 말의 의미는 Garbage Collection(가비지 컬렉션)을 의미한다.

예를 들어, 쓰레기를 청소하는 작업이 수행되면 "가비지 컬렉션이 수행되었다"라고 표현한다.

아니면 짧게 "GC가 발생했다"고 이야기한다.

---

■ Garbage Collector의 진행방식

자바 프로그래밍 과정에 있어 어떤 객체를 생성하더라도 그 객체는 언젠가는 쓰레기가 되어 메모리에서 지워져야만 한다.

예를 들어 "abc"라는 문자열이 있는데, 더 이상 사용할 일이 없다면 메모리에서 삭제되어야 한다.

만약 지워지지 않으면, 더 이상 상요할 일이 없다면 메모리에서 삭제되어야 한다.

허나 계속 지워지지 않고 있다면, 자바 프로그램은 엄청난 메모리가 필요할 것이다.

그래서, C를 사용하여 개발 할 때에는 메모리를 해제하는 작업을 꼭 해줘야만 한다.

하지만, 자바는 그런 작업을 해줄 필요가 없다.

가비지 컬렉터라는 것이 알아서 쓰레기들을 치워주기 때문이다.

JDK 7부터 공식적으로 사용할 수 있는 G1(Garbage First)라는 가비지 컬렉터를 제외한 나머지 JVM은

다음과 같이 영역을 나누어 힙(Heap)이라는 공간에 객체들을 관리한다.

(여기에서 사용되는 영역에 대한 요어들은 JDK의 벤더에 따라서 조금씩 다르다.)

가장 왼쪽에 있는 Young 영역에는 말 그대로 젊은 객체들이 존재하며, Old 역역에는 늙은 객체들이 자리잡게 된다.

그리고 Perm 이라는 영역에는 클래스나 메소드에 대한 정보가 쌓인다.

(Perm에 저장되는 데이터는 더 많지만, 이정도만 알고 있어도 된다.)

Young 영역은 Eden과 두개의 Survivor 영역으로 나뉘는데, 이 중에서 객체를 생성하자마자 저장되는 장소는 Eden이다. 

일반적으로 자바에서 메모리가 살아가는 과정은 다음과 같다.

 ① Eden 영역에서 객체서 생성된다.

 ② Eden 영역이 꽉 차면 살아있는 Survivor 영역으로 복사되고, 다시 Eden 영역을 채우게 된다.

 ③ Survivor 영역이 꽉 차게 되면 다른 Survivor 영역으로 객체가 복사된다.

    이때, Eden 영역에 있는 객체들 중 살아있는 객체들도 다른 Survivor 영역으로 간다.

    즉, Survivor 영역의 둘 중 하나는 반드시 비어 있어야만 한다.

지금까지 서술한 것을 마이너(Minor) GC 혹은 Young GC라고 부른다.

여기서 GC는 가비지 컬렉터가 아니라 가비지 컬렉션을 의미한다.

그러다가, 오래 살아있는 객체들은 Old 영역으로 이동한다.

지속적으로 이동하다가 Old 영역이 꽉 차면 GC가 발생하는데 이것을 메이저(Major) GC 혹은 FUll GC라고 부른다.

일반적으로 Young GC와 Full GC의 속도를 비교하면 Young GC의 속도가 빠르다.

Young GC는 더 작은 공간이 할당되고, 객체들을 처리하는 방식도 다르기 때문이다.

그렇다고, 전체의 힙 영역을 영 영역으로 만들면 장애로 이어질 확률이 매우 높아진다.

오라클 JDK에서 제공하는 GC의 방식은 크게 4가지 버전이 있으며,

JDK 7.0부터 추가된 G1(Garbage First)를 포함하여 총 5가지의 가비지 컬렉터가 존재한다.

정리하면 다음과 같다.

   ● Serial GC

   ● Parallel Young Generation Collector

   ● Parallel Old Generation Collector

   ● CMS : Concurrent Mark & Sweep Collector

   ● G1 : Garbage First

이중에서 WAS로 사용하는 JVM에서 사용하면 안되는 것은 Serial GC이다.

이 GC 방식은 -client 옵션을 지정했을 때 사용된다.

즉 클라이언트용 장비에 최적화된 GC이기 때문에 WAS에서 이 방식을 사용하면 GC의 속도가 매우 느려져

웹 애플리케이션이 엄청 느려진다.

그 외에 다른 GC 방식들은 서로 장단점이 존재하기 때문에 어떤 GC방식이 가장 적합하다고 이야기하기는 매우 어렵다.