출처 : http://d2.naver.com/helloworld/329631

Java의 가비지 컬렉터(Garbage Collector)는 그 동작 방식에 따라 매우 다양한 종류가 있지만 공통적으로 크게 다음 2가지 작업을 수행한다고 볼 수 있습니다.

1. 힙(heap) 내의 객체 중에서 가비지(garbage)를 찾아낸다.
2. 찾아낸 가비지를 처리해서 힙의 메모리를 회수한다.

최초의 Java에서는 이들 가비지 컬렉션(Garbage Collection, 이하 GC) 작업에 애플리케이션의 사용자 코드가 관여하지 않도록 구현되어 있었습니다. 그러나 위 2가지 작업에서 좀 더 다양한 방법으로 객체를 처리하려는 요구가 있었습니다. 이에 따라 JDK 1.2부터는 java.lang.ref 패키지를 추가해 제한적이나마 사용자 코드와 GC가 상호작용할 수 있게 하고 있습니다.

java.lang.ref 패키지는 전형적인 객체 참조인 strong reference 외에도 soft, weak, phantom 3가지의 새로운 참조 방식을 각각의 Reference 클래스로 제공합니다. 이 3가지 Reference 클래스를 애플리케이션에 사용하면 앞서 설명하였듯이 GC에 일정 부분 관여할 수 있고, LRU(Least Recently Used) 캐시 같이 특별한 작업을 하는 애플리케이션을 더 쉽게 작성할 수 있습니다. 이를 위해서는 GC에 대해서도 잘 이해해야 할 뿐 아니라, 이들 참조 방식의 동작도 잘 이해할 필요가 있습니다.

GC와 Reachability

Java GC는 객체가 가비지인지 판별하기 위해서 reachability라는 개념을 사용한다. 어떤 객체에 유효한 참조가 있으면 'reachable'로, 없으면 'unreachable'로 구별하고, unreachable 객체를 가비지로 간주해 GC를 수행한다. 한 객체는 여러 다른 객체를 참조하고, 참조된 다른 객체들도 마찬가지로 또 다른 객체들을 참조할 수 있으므로 객체들은 참조 사슬을 이룬다. 이런 상황에서 유효한 참조 여부를 파악하려면 항상 유효한 최초의 참조가 있어야 하는데 이를 객체 참조의 root set이라고 한다.

JVM에서 메모리 영역인 런타임 데이터 영역(runtime data area)의 구조를 그림으로 그리면 다음과 같다.

그림 1 런타임 데이터 영역(Oracle HotSpot VM 기준)

런타임 데이터 영역은 위와 같이 스레드가 차지하는 영역들과, 객체를 생성 및 보관하는 하나의 큰 힙, 클래스 정보가 차지하는 영역인 메서드 영역, 크게 세 부분으로 나눌 수 있다. 위 그림에서 객체에 대한 참조는 화살표로 표시되어 있다.

힙에 있는 객체들에 대한 참조는 다음 4가지 종류 중 하나이다.

• 힙 내의 다른 객체에 의한 참조
• Java 스택, 즉 Java 메서드 실행 시에 사용하는 지역 변수와 파라미터들에 의한 참조
• 네이티브 스택, 즉 JNI(Java Native Interface)에 의해 생성된 객체에 대한 참조
• 메서드 영역의 정적 변수에 의한 참조

이들 중 힙 내의 다른 객체에 의한 참조를 제외한 나머지 3개가 root set으로, reachability를 판가름하는 기준이 된다.

reachability를 더 자세히 설명하기 위해 root set과 힙 내의 객체를 중심으로 다시 그리면 다음과 같다.

그림 2 Reachable 객체와 Unreachable 객체

위 그림에서 보듯, root set으로부터 시작한 참조 사슬에 속한 객체들은 reachable 객체이고, 이 참조 사슬과 무관한 객체들이 unreachable 객체로 GC 대상이다. 오른쪽 아래 객체처럼 reachable 객체를 참조하더라도, 다른 reachable 객체가 이 객체를 참조하지 않는다면 이 객체는 unreachable 객체이다.

이 그림에서 참조는 모두 java.lang.ref 패키지를 사용하지 않은 일반적인 참조이며, 이를 흔히 strong reference라 부른다.

Soft, Weak, Phantom Reference

java.lang.ref는 soft reference와 weak reference, phantom reference를 클래스 형태로 제공한다. 예를 들면, java.lang.ref.WeakReference 클래스는 참조 대상인 객체를 캡슐화(encapsulate)한 WeakReference 객체를 생성한다. 이렇게 생성된 WeakReference 객체는 다른 객체와 달리 Java GC가 특별하게 취급한다(이에 대한 내용은 뒤에서 다룬다). 캡슐화된 내부 객체는 weak reference에 의해 참조된다.

다음은 WeakReference 클래스가 객체를 생성하는 예이다.

WeakReference<Sample> wr = new WeakReference<Sample>( new Sample());  
Sample ex = wr.get();  
...
ex = null;  

위 코드의 첫 번째 줄에서 생성한 WeakReference 클래스의 객체는 new() 메서드로 생성된 Sample 객체를 캡슐화한 객체이다. 참조된 Sample 객체는 두 번째 줄에서 get() 메서드를 통해 다른 참조에 대입된다. 이 시점에서는 WeakReference 객체 내의 참조와 ex 참조, 두 개의 참조가 처음 생성한 Sample 객체를 가리킨다.

그림 3 Weak Reference 예 1

위 코드의 마지막 줄에서 ex 참조에 null을 대입하면 처음 생성한 Sample 객체는 오직 WeakReference 내부에서만 참조된다. 이 상태의 객체를 weakly reachable 객체라고 하는데, 이에 대한 자세한 내용은 뒤에서 다룬다.

그림 4 Weak Reference 예 2

Java 스펙에서는 SoftReference, WeakReference, PhantomReference 3가지 클래스에 의해 생성된 객체를 "reference object"라고 부른다. 이는 흔히 strong reference로 표현되는 일반적인 참조나 다른 클래스의 객체와는 달리 3가지 Reference 클래스의 객체에 대해서만 사용하는 용어이다. 또한 이들 reference object에 의해 참조된 객체는 "referent"라고 부른다. Java 스펙 문서를 참조할 때 이들 용어를 명확히 알면 좀 더 이해하기 쉽다. 위의 소스 코드에서 new WeakReference() 생성자로 생성된 객체는 reference object이고, new Sample() 생성자로 생성된 객체는 referent이다.

Reference와 Reachability

앞에서 설명한 것처럼, 원래 GC 대상 여부는 reachable인가 unreachable인가로만 구분하였고 이를 사용자 코드에서는 관여할 수 없었다. 그러나 java.lang.ref 패키지를 이용하여 reachable 객체들을 strongly reachable, softly reachable, weakly reachable, phantomly reachable로 더 자세히 구별하여 GC 때의 동작을 다르게 지정할 수 있게 되었다. 다시 말해, GC 대상 여부를 판별하는 부분에 사용자 코드가 개입할 수 있게 되었다.

두 번째 그림에서 몇몇 객체들을 WeakReference로 바꾸어서 예를 들어보면 다음과 같다.

그림 5 Reachable, Unreachable, Weakly Reachable 예제

녹색으로 표시한 중간의 두 객체는 WeakReference로만 참조된 weakly reachable 객체이고, 파란색 객체는 strongly reachable 객체이다. GC가 동작할 때, unreachable 객체뿐만 아니라 weakly reachable 객체도 가비지 객체로 간주되어 메모리에서 회수된다. root set으로부터 시작된 참조 사슬에 포함되어 있음에도 불구하고 GC가 동작할 때 회수되므로, 참조는 가능하지만 반드시 항상 유효할 필요는 없는 LRU 캐시와 같은 임시 객체들을 저장하는 구조를 쉽게 만들 수 있다.

위 그림에서 WeakReference 객체 자체는 weakly reachable 객체가 아니라 strongly reachable 객체이다. 또한, 그림에서 A로 표시한 객체와 같이 WeakReference에 의해 참조되고 있으면서 동시에 root set에서 시작한 참조 사슬에 포함되어 있는 경우에는 weakly reachable 객체가 아니라 strongly reachable 객체이다.

GC가 동작하여 어떤 객체를 weakly reachable 객체로 판명하면, GC는 WeakReference 객체에 있는 weakly reachable 객체에 대한 참조를 null로 설정한다. 이에 따라 weakly reachable 객체는 unreachable 객체와 마찬가지 상태가 되고, 가비지로 판명된 다른 객체들과 함께 메모리 회수 대상이 된다.

Strengths of Reachability

앞에서 설명한 것처럼 reachability는 총 5종류가 있고 이는 GC가 객체를 처리하는 기준이 된다. Java 스펙에서는 이들 5종류의 reachability를 "Strengths of Reachability"라 부른다. 앞의 예제 그림에서는 weakly reachable만 예를 들었기 때문에 WeakReference만 표시하였으나, SoftReference, PhantomReference 등을 이용하여 여러 가지 방식으로 reachability를 지정할 수 있고 이에 따라 각 객체들의 GC 여부는 다양하게 달라지게 된다. 하나의 객체에 대한 참조의 개수나 참조 형태에는 아무런 제한이 없으므로, 하나의 객체는 여러 strong reference, soft reference, weak reference, phantom reference의 다양한 조합으로 참조될 수 있다.

Java GC는 root set으로부터 시작해서 객체에 대한 모든 경로를 탐색하고 그 경로에 있는 reference object들을 조사하여 그 객체에 대한 reachability를 결정한다. 다양한 참조 관계의 결과, 하나의 객체는 다음 5가지 reachability 중 하나가 될 수 있다.

• strongly reachable: root set으로부터 시작해서 어떤 reference object도 중간에 끼지 않은 상태로 참조 가능한 객체, 다시 말해, 객체까지 도달하는 여러 참조 사슬 중 reference object가 없는 사슬이 하나라도 있는 객체
• softly reachable: strongly reachable 객체가 아닌 객체 중에서 weak reference, phantom reference 없이 soft reference만 통과하는 참조 사슬이 하나라도 있는 객체
• weakly reachable: strongly reachable 객체도 softly reachable 객체도 아닌 객체 중에서, phantom reference 없이 weak reference만 통과하는 참조 사슬이 하나라도 있는 객체
• phantomly reachable: strongly reachable 객체, softly reachable 객체, weakly reachable 객체 모두 해당되지 않는 객체. 이 객체는 파이널라이즈(finalize)되었지만 아직 메모리가 회수되지 않은 상태이다.
• unreachable: root set으로부터 시작되는 참조 사슬로 참조되지 않는 객체

다음 예의 경우 객체 B의 reachability는 softly reachable이다.

그림 6 Softly Reachable

root set으로부터 바로 SoftReference를 통해서 B를 참조할 수 있기 때문이다. 만약 root set의 SoftReference에 대한 참조가 없다면(즉, 왼쪽 아래 화살표를 삭제한다면), 객체 B는 phantomly reachable이 된다.

Softly Reachable과 SoftReference

softly reachable 객체, 즉 strong reachable이 아니면서 오직 SoftReferencce 객체로만 참조된 객체는 힙에 남아 있는 메모리의 크기와 해당 객체의 사용 빈도에 따라 GC 여부가 결정된다. 그래서 softly reachable 객체는 weakly reachable 객체와는 달리 GC가 동작할 때마다 회수되지 않으며 자주 사용될수록 더 오래 살아남게 된다. Oracle HotSpot VM에서는 softly reachable 객체의 GC를 조절하기 위해 다음 JVM 옵션을 제공한다.

-XX:SoftRefLRUPolicyMSPerMB=<N>

이 옵션의 기본값은 1000이다.

softly reachable 객체의 GC 여부는 위 옵션의 에 설정한 숫자에 따라 다음 수식에 의해 결정된다.

(마지막 strong reference가 GC된 때로부터 지금까지의 시간) > (옵션 설정값 N) * (힙에 남아있는 메모리 크기)

어떤 객체가 사용된다는 것은 strong reference에 의해 참조되는 것이므로 위 수식의 좌변은 해당 객체가 얼마나 자주 사용되는지를 의미한다. 옵션 설정값이 1000이고 남아 있는 메모리가 100MB이면, 수식의 우변은 1,000ms/MB * 100MB = 100,000ms = 100sec, 즉 100초가 된다(옵션 이름 마지막이 MSPerMB로 끝나므로 옵션 설정값의 단위는 ms/MB임을 알 수 있다). 따라서 softly reachable 객체가 100초 이상 사용되지 않으면 GC에 의해 회수 대상이 된다. 힙에 남아있는 메모리가 작을수록 우변의 값이 작아지므로, 힙이 거의 소진되면 대부분의 softly reachable 객체는 모두 메모리에서 회수되어 OutOfMemoryError를 막게 될 것이다.

softly reachable 객체를 GC하기로 결정되면 앞서 설명한 WeakReference 경우와 마찬가지로 참조 사슬에 존재하는 SoftReference 객체 내의 softly reachable 객체에 대한 참조가 null로 설정되며, 이후 이 softly reachable객체는 unreachable 객체와 마찬가지가 되어 GC의해 메모리가 회수된다.

Weakly Reachable과 WeakReference

weakly reachable 객체는 특별한 정책에 의해 GC 여부가 결정되는 softly reachable 객체와는 달리 GC를 수행할 때마다 회수 대상이 된다. 앞서 설명한 것처럼 WeakReference 내의 참조가 null로 설정되고 weakly reachable 객체는 unreachable 객체와 마찬가지 상태가 되어 GC에 의해 메모리가 회수된다. 그러나 GC가 실제로 언제 객체를 회수할지는 GC 알고리즘에 따라 모두 다르므로, GC가 수행될 때마다 반드시 메모리까지 회수된다고 보장하지는 않는다. 이는 softly reachable 객체는 물론 unreachable 객체도 마찬가지이다. GC가 GC 대상인 객체를 찾는 작업과 GC 대상인 객체를 처리하여 메모리를 회수하는 작업은 즉각적인 연속 작업이 아니며, GC 대상 객체의 메모리를 한 번에 모두 회수하지도 않는다.

LRU 캐시와 같은 애플리케이션에서는 softly reachable 객체보다는 weakly reachable 객체가 유리하므로 LRU 캐시를 구현할 때에는 대체로 WeakReference를 사용한다. softly reachable 객체는 힙에 남아 있는 메모리가 많을수록 회수 가능성이 낮기 때문에, 다른 비즈니스 로직 객체들을 위해 어느 정도 비워두어야 할 힙 공간이 softly reachable 객체에 의해 일정 부분 점유된다. 따라서 전체 메모리 사용량이 높아지고 GC가 더 자주 일어나며 GC에 걸리는 시간도 상대적으로 길어지는 문제가 있다.

ReferenceQueue

phantomly reachable 객체의 동작과 PhantomReference를 설명하기 전에 java.lang.ref 패키지에서 제공하는 ReferenceQueue 클래스에 대해 설명할 필요가 있다.

SoftReference 객체나 WeakReference 객체가 참조하는 객체가 GC 대상이 되면 SoftReference 객체, WeakReference 객체 내의 참조는 null로 설정되고 SoftReference 객체, WeakReference 객체 자체는 ReferenceQueue에 enqueue된다. ReferenceQueue에 enqueue하는 작업은 GC에 의해 자동으로 수행된다. ReferenceQueue의 poll() 메서드나 remove() 메서드를 이용해 ReferenceQueue에 이들 reference object가 enqueue되었는지 확인하면 softly reachable 객체나 weakly reachable 객체가 GC되었는지를 파악할 수 있고, 이에 따라 관련된 리소스나 객체에 대한 후처리 작업을 할 수 있다. 어떤 객체가 더 이상 필요 없게 되었을 때 관련된 후처리를 해야 하는 애플리케이션에서 이 ReferenceQueue를 유용하게 사용할 수 있다. Java Collections 클래스 중에서 간단한 캐시를 구현하는 용도로 자주 사용되는 WeakHashMap 클래스는 이 ReferenceQueue와 WeakReference를 사용하여 구현되어 있다.

SoftReference와 WeakReference는 ReferenceQueue를 사용할 수도 있고 사용하지 않을 수도 있다. 이는 이들 클래스의 생성자 중에서 ReferenceQueue를 인자로 받는 생성자를 사용하느냐 아니냐로 결정한다. 그러나 PhantomReference는 반드시 ReferenceQueue를 사용해야만 한다. PhantomReference의 생성자는 단 하나이며 항상 ReferenceQueue를 인자로 받는다.

ReferenceQueue<Object> rq = new ReferenceQueue<Object>(); PhantomReference<Object> pr = new PhantomReference<Object>(referent, rq);  

SoftReference, WeakReference는 객체 내부의 참조가 null로 설정된 이후에 ReferenceQueue에 enqueue되지만, PhantomReference는 객체 내부의 참조를 null로 설정하지 않고 참조된 객체를 phantomly reachable 객체로 만든 이후에 ReferenceQueue에 enqueue된다. 이를 통해 애플리케이션은 객체의 파이널라이즈 이후에 필요한 작업들을 처리할 수 있게 된다. 더 자세한 내용은 다음 절에서 설명한다.

Phantomly Reachable과 PhantomReference

softly reachable과 weakly reachable, phantomly reachable은 많이 다르다. 이를 설명하기 위해서는 먼저 GC 동작을 설명해야 한다. GC 대상 객체를 찾는 작업과 GC 대상 객체를 처리하는 작업이 연속적이지 않 듯이, GC 대상 객체를 처리하는 작업과 할당된 메모리를 회수하는 작업도 연속된 작업이 아니다. GC 대상 객체를 처리하는 작업, 즉 객체의 파이널라이즈 작업이 이루어진 후에 GC 알고리즘에 따라 할당된 메모리를 회수한다.

GC 대상 여부를 결정하는 부분에 관여하는 softly reachable, weakly reachable과는 달리, phantomly reachable은 파이널라이즈와 메모리 회수 사이에 관여한다. strongly reachable, softly reachable, weakly reachable에 해당하지 않고 PhantomReference로만 참조되는 객체는 먼저 파이널라이즈된 이후에 phantomly reachable로 간주된다. 다시 말해, 객체에 대한 참조가 PhantomReference만 남게 되면 해당 객체는 바로 파이널라이즈된다. GC가 객체를 처리하는 순서는 항상 다음과 같다.

1. soft references
2. weak references
3. 파이널라이즈
4. phantom references
5. 메모리 회수

즉, 어떤 객체에 대해 GC 여부를 판별하는 작업은 이 객체의 reachability를 strongly, softly, weakly 순서로 먼저 판별하고, 모두 아니면 phantomly reachable 여부를 판별하기 전에 파이널라이즈를 진행한다. 그리고 대상 객체를 참조하는 PhantomReference가 있다면 phantomly reachable로 간주하여 PhantomReference를 ReferenceQueue에 넣고 파이널라이즈 이후 작업을 애플리케이션이 수행하게 하고 메모리 회수는 지연시킨다.

앞서 설명한 것처럼 PhatomReference는 항상 ReferenceQueue를 필요로 한다. 그리고 PhantomReference의 get() 메서드는 SoftReference, WeakReference와 달리 항상 null을 반환한다. 따라서 한 번 phantomly reachable로 판명된 객체는 더 이상 사용될 수 없게 된다. 그리고 phantomly reachable로 판명된 객체에 대한 참조를 GC가 자동으로 null로 설정하지 않으므로, 후처리 작업 후에 사용자 코드에서 명시적으로 clear() 메서드를 실행하여 null로 설정해야 메모리 회수가 진행된다.

이와 같이, PhantomReference를 사용하면 어떤 객체가 파이널라이즈된 이후에 할당된 메모리가 회수되는 시점에 사용자 코드가 관여할 수 있게 된다. 파이널라이즈 이후에 처리해야 하는 리소스 정리 등의 작업이 있다면 유용하게 사용할 수 있다. 그러나 개인적으로는 PhantomReference를 사용하는 코드를 거의 본 적이 없으며, 그 효용성에 대해서는 의문이 있다.

마치며

Java의 Reference는 그 선후 관계와 용어가 복잡해서 글로 쉽게 풀어쓰기가 어려워 본문이 꽤 장황해졌다. 본문의 내용을 간단히 요약하면 다음과 같다.

• Java GC는 GC 대상 객체를 찾고, 대상 객체를 처리(finalization)하고, 할당된 메모리를 회수하는 작업으로 구성된다.
• 애플리케이션은 사용자 코드에서 객체의 reachability를 조절하여 Java GC에 일부 관여할 수 있다.
• 객체의 reachability를 조절하기 위해서 java.lang.ref 패키지의 SoftReference, WeakReference, PhantomReference, ReferenceQueue 등을 사용한다.

개인적으로는 내부 캐시 등을 구현하고자 하는 대부분의 애플리케이션에서는 WeakReference 혹은 이를 이용한 WeakHashMap만으로도 충분하다고 생각한다. 다른 애플리케이션에서는 가끔 SoftReference를 사용하는 경우도 있지만, PhantomReference는 거의 예제가 없으며 그만큼 불필요할 것이다. 이들 Java Reference들과 관련된 GC 동작을 잘 이해하면 Java의 heap 메모리 문제에서 더욱 유연한 애플리케이션 작성에 크게 도움이 될 것이다.

• JAVA의 객체가 garbage collection 대상이 되는 순간은?
  1. reference가 영원히 영역을 벗어남 (ex. 지역 변수로 선언한 객체의 메소드의 영역을 벗어남)
  2. reference에 다른 객체를 대입
  3. reference를 직접 'null'로 설정
  but, 위 방법 외에 참조를 약하게 만들어 GC 대상이 되도록 만들 수 있다.
  
  

Strong Reference > Soft Reference > Weak Reference > Phantom Reference

• Strong Reference
  : 일반적으로 new를 통해서 객체를 생성하게 되면 생기게 되는 참조.
  : 참조에 대해서 해지하지 않는다면 그 메모리는 절대 수거되지 않는다.
  
  
• Soft Reference
  : GC에 의해 수거될 수도 있고, 수거되지 않을 수도 있다.
  : 메모리 상태에 따라 결정
  
  
• Weak Reference
  : GC가 발생하기 전까지는 참조를 유지한다.
  : GC가 발생하는 순간 무조건 수거된다.
  : 객체 캐시에 유용 (안드로이드에서 그림이 포함된 listView 등)
  
  
• Phantom Reference
  : 가장 약한 참조
  : GC가 발생 전 메모리에서 정리된다. (finalize() 호출 후)
  : 내부적으로 유지하고 있지만, 객체를 다시 꺼내오면 null 이다 
  
  - ReferenceTest.java

  package kr.co.ioacademy; //iocademy 윤찬식 강사님
  
  import java.lang.ref.SoftReference;
  import java.lang.ref.WeakReference;
  import java.util.LinkedList;
  import java.util.List;
  
  // 강한 참조(Strong Reference)
  // 일반적으로 new를 통해서 객체를 생성하게 되면 생기게 되는 참조.
  
  // 강한 참조를 통해 참조되고 있는 객체는 절대 가비지 컬렉션의 대상에서
  // 제외된다.
  // 자바에서 아무리 자동적으로 메모리가 수거된다고 하지만, 
  // 참조에 대해서 해지하지 않는 다면 그 메모리는 절대 수거되지 않는다.
  //  (참조 = null , 참조 = 다른객체)
  
  // OutOfMemory를 방지하기 위해서는 약한 형태의 참조를 사용해야 한다.
  //  SoftReference<>, WeakReference<>
  
  // Soft Reference
  // 생성 방법 : SoftReference<Data> r
              // = new SoftReference<Data>(new Data);
  // 동작 : 강한 참조와 다르게 GC에 의해 수거될 수도 있고, 수거되지 않을 수도 있다.
  //  메모리에 충분한 여유가 있다면 GC가 수행되고 있다고 하더라도 수거되지 않는다.
  //  하지만 out of memory의 시점이 가깝다면, 수거될 확률이 높다.
  
  // Weak Reference
  //생성 방법 : WeakReference<Data> r
  // = new WeakReference<Data>(new Data);
  
  // WeakReference에 의해 참조된 객체는 가비지 컬렉션이 발생하기 전까지는 참조를 유지
  // 하지만 GC가 발생하는 순간 무조건 수거된다.
  // WeakReference가 사라지는 시점이 GC의 실행 주기와 일치한다.
  // 이를 이용하면 짧은 주기에 자주 사용되는 객체를 캐시할 때 유용하다.
  // => WeakHashMap
  // WeakHashMap<K,V>
  
  // PhantomReference
  
  class BigData {
  	private int[] array = new int[5000]; // 20000byte, 20K
  }
  
  public class ReferenceTest {
  
  	private List<WeakReference<BigData>> refs = new LinkedList<>();
  
  	public void referenceTest() {
  		try {
  			for (int i = 0; true; i++) {
  				refs.add(new WeakReference<BigData>(new BigData()));
  			}
  		} catch (OutOfMemoryError ofm) { // Strong일 경우 out of memory 발생
  			System.out.println("out of memory!");
  		}
  	}
  
  	public static void main(String[] args) {
  		System.out.println("run");
  		// Thread.sleep(10 * 1000);
  		ReferenceTest test = new ReferenceTest();
  		test.referenceTest();
  		System.out.println("finish");
  	}
  	
  }
  

  
  - WeakSingleton.java

  package kr.co.ioacademy; //iocademy 윤찬식 강사님
  import java.lang.ref.WeakReference;
  
  public class WeakSingleton {
  	private static WeakReference<WeakSingleton> instance
  	 = new WeakReference<WeakSingleton>(null);
  
  	public static WeakSingleton getInstance()
  	{
  		WeakSingleton m = instance.get();
  		if (m != null)
  			return m;
  		
  		synchronized (WeakSingleton.class) {	
  			
  			System.out.println("Create new instance");
  			
  			m = new WeakSingleton();
  			instance = new WeakReference<WeakSingleton>(m);		
  		}
  		
  		return m;
  	}
  	
  	public static void main(String[] args) {
  		WeakSingleton w = WeakSingleton.getInstance();
  		
  		// System.gc();
  		
  		w = WeakSingleton.getInstance();
  	}
  }
  

출처: http://loveinsky.tistory.com/entry/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-1-2

앞에서 JAVA 에 대한 개략적인 특징들을 알아보았다. 그 개략적인 특징들을 중심으로 이제부터는 JAVA 의 세심한 부분에서의 특징들을 분석할 것인데, 우선 첫번째로 JAVA Development 과정을 알아볼 것이다. 어떻게 작성하고, 어떤 방식으로 '소스 코드'가 해석되고, 그 해석된 코드는 어떤 방식으로 실행되는지 전반적인 과정을 이번 1 (2) 에서 알아보고, 다음 글인 2 장에서 부터는 다른 언어와 차별화를 두는 JAVA의 특성인 '객체 지향성(Object-Oriented)'의 특성들에 대해 알아보자.

우선 컴퓨터 언어는 3 가지 종류로 분류된다.

   저수준 언어 (Low-Level)

1) 기계어 (Machine Language) : 0101 와 같이 오직 컴퓨터만 이해하는 언어로 CPU에 내장된 명령들을 직접 사용하는 것으로, 수행시간이 빠르다. 기종마다 기계어가 다르기 때문에 언어의 호환성이 없다. 반면에 Java의 경우는 위에서 설명하였듯이 JVM을 이용해 '바이너리 코드'를 각 기계에 맞게 실행시켜준다. 

2) 어셈블리어 (Assembly Language) : 단순한 언어로 기계어와 고수준 언어 중간지점 개념의 언어. 기계어와 1:1로 대응되는 기호로 이루어진 언어로 이도 기계어와 마찬가지로 언어의 호환성이 없다.

   고수준 언어 (High-Level)

3) 고수준 언어 (High-Level) - C, C++, C#, Java 등 인간이 실생활에서 사용하는 자연어와 비슷한 형태와 구조를 갖는다. 실행을 하기 위해서는 컴퓨터가 이해할 수 있는 기계어로 반드시 해석(Translate)되야하는데, Translate 하는 프로그램에는 컴파일러나 인터프리터가 사용된다.

컴파일러와 인터프리터는 무엇인가? 간단하게 설명하자면, 고수준 언어를 저수준 언어인 기계어로 바꾸어주는 것이다. 이렇게 번역된 프로그램은 0101과 같은 기계어로 구성되어있으며, 일반적으로는 Object Program (목적 프로그램 / .obj 또는 .o) 이라고 부르며, Java에서는 Class Program (클래스 프로그램 / .class) 이라고 부른다. 컴파일러와 인터프리터는 이렇게 기계어로 바꾸어주는 똑같은 목적을 지녔지만, 방법면에서는 이 두 방법을 따로 분류시킬 정도의 상이한 차이를 보인다.

1. 컴파일러 Compiler
- 컴파일러는 '고수준 언어'를 읽어내어 '목적 프로그램'으로 번역한 후, Linking 작업을 통해 컴퓨터에서 실행 가능한 실행 프로그램인 ‘기계어 프로그램’을 만들어낸다. 아래 그림에서 점선 박스 안에 있는 과정이 컴파일러의 '컴파일' 과정이다.

2. 인터프리터 Interpreter

- 인터프리터는 ‘고수준 언어 프로그램’을 직접적으로 바로 실행 한다. 그렇기 때문에 목적 프로그램을 만들지 않는다.프로그램을 '인터프리트'하는 것은 그 프로그램의 ‘기계어(기계 코드) 프로그램’을 실행하는 것 보다 느리다. 아래 점선 박스 안에 있는 것이 인터프리터의 과정이다.

인터프리터가 컴파일러에 비해 실행 속도가 느린 이유는 '기계어 프로그램'는 모든 순서 처리와 기타 다른 요소들을 다 정리한 후에 '목적 파일'이라는 하나의 통 파일로 제작된 것이기 때문이다. 기계어들이 처음부터 끝까지 정리된 상태에서 실행하는 것과, 기계어를 처음부터 끝까지 한 줄, 한 줄 해석해 나가는 것이 상식적으로 느리다. 추가적으로 컴파일러는 번역속도 면에서는 인터프리터 보다 느리다. 이유는 위와 같다. 한 줄을 번역하는 것이, 전체를 번역하는 것보다 빠른것은 당연하다.

Java 도 역시 '고수준 언어' 중 하나로, 해석 과정을 거쳐야지 비로소 실행을 할 수 있게된다.

' 그럼, Java 는 컴파일러를 사용하는 컴파일러 언어일까? 인터프리터를 이용하는 인터프리터 언어일까? '

Java 는 '고수준 언어'이기 때문에 Java 프로그램을 개발하려고 하는 프로그래머들은 어떠한 종류의 프로그램을 개발 하려고하던간에 우선 맨 처음 소스 프로그램을 Java 코드로 작성해야 한다. 이를 프로그래밍의 가장 초기 과정 Edit라 하며 컴파일러와 인터프리터의 사용은 그 다음 과정에서 사용된다. 전체 프로그래밍 과정은 아래와 같다.

1. Edit

2. Compile

3. Run ( Interpret )

   - Load

   - Verify

   - Execute  

Edit 다음 이 소스 프로그램을 기계어로 바꾸어야 한다. 위 2. 번 Compile을 보면 알 수 있듯이, 이 바꾸는 과정을 Compile 이라고 부르고 이 과정은 Compiler 를 통해 하게된다.

Compile 을 하면 .class 라는 확장자를 지닌 'Bytecode 프로그램'이 생겨난다. 그 다음 3. Run 과정에서는 2. Compile해서 나온 'Bytecode 프로그램'을 실행해서 원하는 결과를 출력하기 위하여, JVM 이라는 프로그램을 사용하게 된다. JVM 은 Bytecode 들을 C 언어에서와 같이 따로 Link 같은 결과를 거쳐 .exe 확장자를 가진 '실행 프로그램'과 같은 '결과 프로그램'을 만들지 않고, Bytecode 프로그램에 있는 코드 그대로 한 줄, 한 줄 씩 읽어서 Interpret 방법으로 프로그램을 직접 바로 실행한다. 한 줄 한 줄 씩 Interpret 하는 과정에서 JVM은 사용자 User 가 사용하고 있는 H/W 와 OS 들에 맞추어 Bytecode를 '맞춤 실행' 해준다. 이 '맞춤 실행'은 Java의 큰 특징이기도 하다.

Java의 특징 중 하나인 JVM 가 수행하는 Interpret 과정( Run 과정 )은 단순하게 하나의 과정으로 보이지만, 사실은 하나의 과정속에 여러 추가 과정들이 포함되어 있다. Interpret ( Run ) 의 자세한 과정은 다음과 같다.

Java 개발에서 Compiler 와 JVM 은 JDK에 포함되어있고, 이는 Oracle 홈페이지에서 언제든지 최신버전을 받을 수 있다. 이 '전체 프로그래밍 과정'을 수행하기 위해서 우리는

1. Edit 을 위해 메모장을 사용하고,

2. Compile 을 위한 JDK 를 다운받아서 DOS-MS (cmd.exe) 내에서 컴파일을 수행하고,

3. JDK 에 포함되어있는 JVM 을 이용하여 컴파일되어 새로 생긴 Bytecode 들을 실행해야한다.

이렇게 3 가지 과정을 순서대로 각자 수행하기에는 귀찮은 것이 사실이다. 이 과정들을 하나의 프로그램에서 간편하게 처리할 수 있게 해주기 위해, 예전 C 언어의 등장에서 부터 사람들이 쉽게 개발을 할 수 있게 도와주는 많은 '통합 Tool' 들이 많이 존재해 왔다. 에디터, 컴파일러, 실행기, 디버거 등의 개발에 필요한 모든 환경들을 하나로 모아준 것을 Integrated Development Environments (통합 개발 환경, IDEs) 이라고 부른다. 필자가 어렸을 때 읽었던 '터보 C'책에 나온 '터보 C' 라는것도 이 IDE 이며, 현재 사람들이 많이들 사용하는 Visual Studio 등의 Visual 시리즈들도 이 IDE 이다. Java는 현재 시중에 나와 있는 많은 언어 IDE 와는 달리 free IDE 인 Eclipse 가 존재한다. 무료임에도 매우 강력한 환경을 제공해 주기에 사람들이 많이 애용하고, 앞으로 작성할 모든 Java 관련 포스트도 다 Eclipse 를 기반으로 할 것이다.  

다음은 JAVA 의 가장 중요한 특징인 객체 지향성 에 대해 살펴볼 것이다. Class 에 대한 내용은 단순히 객체 개념 에서 끝나는 것이 아니라 그에 관련된 기타 다른 내용들도 많기 때문에, 1 장 처럼 2장 - (1), (2) 이런 식으로 나누어서 설명할 생각이다.