Multiple threads and garbage collection in Java

Question

Can someone give me some advice on this? I am reading in an old text and some notes from my teacher that when using multiple threads with Java it's necessary to write a special program for garbage collection.

Does this still apply in Java SE6 and above? If it does could someone provide the standard way to do this.

Answer 1

As far as I know, as long if nothing is pointing to an object, that object get's freed by the garbage collector.

Java's garbage collector is very robust in terms of circular referencing, I don't see why It won't work with multiple threads running at the same time.

So it is safe for you to assume that you don't need to write a special program for garbage collection, because java will do it for you very effectively.

If you want to free objects in java, just make sure that no variables are referencing your object. (Including structures (lists, arrays, etc) from java collections or other libraries)

Answer 2

Using a garbage collector makes writing multi-threaded code easier. This is because manual freeing of resources in a multi-threaded context is hard to get right. With GC its something you don't need to worry about most of the time.

I am reading that when using multiple threads it's necessary to write a special program for garbage collection.

I don't believe this was ever the case.

Does this still apply in SE6 and above and if so is there a standard way to do this.

The standard way to do this is to not reference objects you don't need. eg if you have a local variable you don't need, let it drop out of scope.

It doesn't have to be complicated.

Answer 3

This article from JavaWorld in 2003 , J2SE 1.4.1 boosts garbage collection , has this to say about the Java garbage collection prior to J2SE 1.4.1:

Mark and sweep is a "stop-the-world" garbage collection technique; that is, all application threads stop until garbage collection completes, or until a higher-priority thread interrupts the garbage collector. If the garbage collector is interrupted, it must restart, which can lead to application thrashing with little apparent result. The other problem with mark and sweep is that many types of applications can't tolerate its stop-the-world nature. That is especially true of applications that require near real-time behavior or those that service large numbers of transaction-oriented clients.

An article in Dr. Dobbs from 2009 , G1: Java's Garbage First Garbage Collector , has this to say about Java garbage collector before SE 6.

Until recently, Java SE came with two main collectors: the parallel collector, and the concurrent-mark-sweep (CMS) collector -- see the sidebar Parallelism and Concurrency. As of the latest Java SE 6 update release, the G1 collector is another option. The plan is for G1 to eventually replace CMS as a low-pause, soft real-time collector. Let's take a look at how it works.

So it may be that prior to SE 6 some additional precautions to assist with Java garbage collection may have helped, especially with multi-threaded applications with a fair amount of temporary variables generating garbage that needed collecting. However this should entail at most an explicit call to the garbage collector during slow times. Writing something special would seem very unusual.

However things are much more improved than they were. Plus garbage collection can vary between different versions of Java Virtual Machines.

So what may have been true years ago is almost definitely not true now with current technology.

This posting, How to monitor Java memory usage? , discusses monitoring Java memory usage as well as some of the pros and cons of calling the garbage collector explicitly.

Oracle has a Java Garbage Collection Basics tutorial that covers Java SE 7 Hotspot JVM.

Answer 4

Use following code to call garbage collector explicitly

Runtime runtime = Runtime.getRuntime(); 
runtime.gc();

But it is not needed, jvm will automatically handle correct timely running of GC.

Answer 5

Almost certainly your instructor's notes are stating (correctly) that since Java is a multithreaded environment, more care is needed when implementing the garbage collector inside the Java run time environment than would be necessary if only a single thread were involved. This is true of any multithreaded environment.

As others have said, you the programmer don't see any of this complexity. That's the gift of automatic memory management that gc provides.