never return to free the lock; therefore, the garbage collection thread will block forever and hang
the Java VM.
Keep this situation in mind when overriding the finalize() method. When finalize() is
called by the garbage collection thread, all other threads running in the VM become suspended.
2. Performance: Access to synchronized objects
We have seen many situations where the performance of Java code is diminished when accessing
synchronized methods or objects. This should not be a surprise, as calling synchronized methods
involved locking a monitor before accessing the method. We can't stress this point enough. It
seems simple enough, but programmers often fall into it. In one customer situation, a Hashtable
object was being used to cache results obtained from a database. Using a Hashtable for this
purpose is not wrong, in fact it is a common technique. However, if the program is to scale up to
several concurrent database accesses at any given time, the Hashtable becomes a bottleneck to
the program's performance. Since access to a Hashtable object is synchronized, only one thread
is allowed to modify the object at any given time.
A simple solution to a situation like this is to use multiple Hashtable objects and then distribute
access to the objects so that you can have some level of concurrency. In the case we have outlined,
when multiple Hashtable objects were used to cache the database data, a hundredfold increase
in performance was gained.
3. More problems with the garbage collection thread
Usually, the garbage collector works exactly the way intended and you, the programmer can
ignore it completely. In certain cases under certain system requirements, you may wish to change
some details of its behavior. Don't even think about this unless you see specific problems.
We have run into a number of issues with the garbage collection thread in the Java VM. Most of
the problems revolve around the fact that when the garbage collection thread runs, it suspends all
of the other threads in the Java VM. The fact that all the threads in the VM are suspended can be a
cause of concern when programming multithreaded programs in Java, but the simple act of
garbage collection can also cause some annoying problems. For example, say you have a Java
program that needs a lot of memory for a local cache that you wrote. If the memory heap
requirements are large, say 500 MB or more, the simple act of garbage collection can take quite a
bit of time to complete. In this example, since the heap requirements are large and system garbage
collection does not usually kick in until 75% of the heap is used, it can cause the entire Java VM
to halt for quite a bit of time while it cleans up the heap.
A simple solution to a problem like this is to perform garbage collection more often or to define
your own garbage collection class. For example, you could have a thread that sleeps for a given
amount of time and then wakes up and calls for garbage collection. You may think that this would
cause even further program delays, but the simple fact that garbage collection is performed more
often means that the amount of heap it needs to clean up is smaller. This means that the delay
caused during garbage collection is smaller. In the example where the heap is huge, it is better to
have very small delays introduced during program execution than to have a single large halt while
the entire heap is collected.
4. Make synchronized code sections as small as possible
A synchronized method invocation is one of the most time- consuming operations in Java.
Therefore, you want to avoid its use as much as possible. We realize that when writing threaded
programs in Java, you will need to use synchronized code. The synchronized keyword is most
commonly used in method signatures. This is a valid use of the keyword, but in many cases the
Search WWH :