Understanding the Reference Handler thread

Question

I am continuing my path to deep understanding of Java Thread. Unfortunately my Java Certification didn\'t cover that part, so the only way of learning is to post a series of dum

Answer 1

Wow, too deep for me. I can only answer one or two of your questions.

"Native Method" simply means the implementation of that method is in some native (i.e. C or C++) library. Once the call stack has "gone native", the JVM can no longer monitor it. No way for it to provide additional stack information.

"Unknown Source" likely means the code was compiled with optimization turned on and debugging info turned off (-g flag?). This eliminates the file/line information from the .class file.

Answer 2

1) The Finalizer Thread calls finalizer methods. The Reference Thread has a similar purpose.

http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Core/lang/java/lang/ref/Reference.java.htm

The OpenJDK source states its is a

High-priority thread to enqueue pending References

The GC creates a simple linked list of references which need to be processed and this thread quickly adds them to a proper queue. The reason this is done in two phases is that the GC does nothing but find the References, this thread calls code which handles those references e.g. Call Cleaners, and notifies ReferenceQueue listeners.

2) A lock is acquired for a synchronized method before it is entered.

3-5) covered by Joachim ;)

Answer 3

1. I suspect it handles running finalizers for the JVM. It's an implementation detail and as such not specified in the JVM spec.
2. This only means that the java.lang.ref.Reference$Lock was locked in the method mentioned in the line preceding it (i.e in ReferenceHandler.run().
3. "Native Method" simply means that the method is implemented in native (i.e. non-Java) code (think JNI).
4. Unknown Source only means that the .class file doesn't contain any source code location information (at least for this specific point). This can happen either when the method is a synthetic one (doesn't look like it here), or the class was compiled without debug information.
5. When a thread waits on some object, then it must have locked that object at some point down the call trace, so you can't really have a waiting on without a corresponding locked.