JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 060 contents

http://weblogs.java.net/blog/mandychung/archive/2005/11/thread_dump_and.html
Thread Dump and Concurrency Locks (Page last updated November 2005, Added 2005-11-29, Author Mandy Chung, Publisher java.net). Tips:

• Thread dumps are very useful for diagnosing synchronization related problems such as deadlocks
• Ctrl-\ or sending a QUIT signal on Solaris/Linux or Ctrl-Break on Windows has been a common way to get a thread dump of a running application. The application prints a thread dump to standard output and also detects if there is any deadlock involving object monitors.
• jstack is a new troubleshooting utility introduced in JSE 5.0 that provides a new way to obtain a thread dump
• jconsole is JMX-complaint GUI tool which allows you to get a thread dump on the fly.
• The Threads tab in the Mustang (6.0) jconsole now shows which synchronizer a thread is waiting to acquire when the thread is blocked to lock a ReentrantLock and also which thread is owning that lock.

http://blogs.sun.com/roller/page/alanb?entry=jstack
jstack (Page last updated October 2005, Added 2005-11-29, Author Alan Bateman, Publisher Sun). Tips:

• jstack prints the stack traces of all java threads for a given process or core dump.
• The jstack -m option will print a mixed-mode stack so that you can see native frames in addition to the java frames.
• On Solaris 10 pstack has been updated to print java method names for interpreted, compiled and inlined java methods, printing a mixed-mode stack and the output similar to jstack -m.
• If the VM is hung then a thread dump can still be forced using the jstack -F option.
• The jstack "-l" option prints information about java.util.concurrent.locks - without the "-l" option the thread dump only includes information on monitors. This option can be expensive if the heap is large.

http://www.ibm.com/developerworks/java/library/j-jtp11225/
Plugging memory leaks with weak references (Page last updated November 2005, Added 2005-11-29, Author Brian Goetz, Publisher IBM). Tips:

• The most common source of unintentional object retention is the use of a Map to associate metadata with transient objects, which prevents the object from being garbage collected when the rest of the application no longer references the transiaent object.
• The first sign that your program has a memory leak is usually that it throws an OutOfMemoryError or starts to exhibit poor performance because of frequent garbage collection.
• Use the -verbose:gc or the -Xloggc option to get a diagnostic message every time the GC runs, including how long it took, the current heap usage, and how much memory was recovered.
• It is reasonable to enable GC logging in production by default in the event you ever need to analyze memory problems or tune the garbage collector.
• If memory usage continues to trend upwards even though the application has completed its initialization and its load is not increasing, the program is probably retaining objects generated in the course of processing prior requests.
• Any memory profiler can produce snapshots of the heap broken down by object class -- the built-in hprof tool can also do the trick.
• To use hprof and instruct it to track memory usage, invoke the JVM with the -Xrunhprof:heap=sites option.
• When you create a weak reference to an object, you do not extend the lifetime of the referent at all; you simply maintain an alternate way to reach it while it is still alive.
• WeakHashMap can be used to refer to objects (if the object is a key in the map) that will be available while the object is alive, but will be automatically dereferenced when the object is no longer referenced elsewhere in the application.
• When a weak reference has been created with an associated reference queue and the referent becomes a candidate for GC, the reference object (not the referent) is enqueued on the reference queue after the reference is cleared. The application can then retrieve the reference from the reference queue and learn that the referent has been collected so it can perform associated cleanup activities, such as expunging the entries for objects that have fallen out of a weak collection.

http://java.sun.com/developer/JDCTechTips/2005/tt0816.html
Locks and a bit of InetAddress (Page last updated August 2005, Added 2005-11-29, Author John Zukowski, Publisher Sun). Tips:

• InetAddress.isReachable() provides a way to check for a host for reachability (i.e. equivalent to "ping").
• Name lookups and reverse lookups can be expensive operations (i.e slow).
• The system uses a cache mechanism for name lookups and reverse lookups for both performance and security reasons. Once you look up a host, you always get the same one for subsequent lookups, and the results can't change between lookups.
• The java.util.concurrent.locks package concurrency utilities support lock timeouts, multiple condition variables per lock, read-write locks, and the ability to interrupt a thread waiting for a lock.
• The typical Lock usage sequence is: get a lock, access the protected resource, and release the lock, e.g. Lock l = ...; l.lock(); try {/*access resource*/... } finally {l.unlock();} . This is functionally similar to synchronizing on the lock variable.
• If you use Lock.lockInterruptibly() instead of Lock.lock(), then the blocking attempt to acquire the lock can be interrupted by another thread, and the lockInterruptibly() call would throw an InterruptedException instead of acquiring the lock. Typical usage would be e.g. Lock l = ...; try{ l.lockInterruptibly(); try {/*access resource*/... } finally {l.unlock();} } catch (InterruptedException e) { /*lock acquisition interrupted*/...}
• Lock.tryLock() tries to acquire a lock and returns immediately i.e. it doesn't block waiting for the lock to come free.
• Lock.tryLock(timeout, timeunit) tries to acquire a lock for the specified timeout, and returns if teh lock is acquired within the specified timeout, or if not acquired it will return when the timeout is reached. The TimeUnit class allows you to specify units as seconds, milliseconds, microseconds, or nanoseconds.
• java.util.concurrent.locks package includes three implementations of the Lock interface: ReentrantLock; ReentrantReadWriteLock.ReadLock; ReentrantReadWriteLock.WriteLock.
• Use a read-write lock when reads are long and frequent, and writes are infrequent: ReadWriteLock rwl = new ReentrantReadWriteLock(); Lock readLock = rwl.readLock(); Lock writeLock = rwl.writeLock();

http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&dc=DB520&uid=swg21164724&loc=en_US&cs=utf-8&lang=en
Preventing mark stack overflows (Page last updated October 2005, Added 2005-11-29, Author IBM, Publisher IBM). Tips:

• A mark stack overflow can be caused by an IBM Java JVM maximum heap size that is set too high.
• The best way to reduce mark stack overflows is to reduce the Java maximum heap size.
• Any mark stack overflow results in a scan of the entire Java heap, which is expensive in terms of CPU utilization.
• Adding the -Xgcpolicy:optavgpause JVM argument reduces and makes pause times more consistent when the heap occupancy rises which helps address mark stack overflows. However, it also reduces throughput by approximately 5% depending on the application.
• The -Xgcthreads is set by default to the number of CPUs; no advantage is gained by increasing the number of helper threads above the default setting and IBM support strongly recommends not to do this.
• Reducing or disabling helper threads prevents concurrent operations at the cost of performance.

http://www.developer.com/java/ent/article.php/3560796
High-Availability Clustering in Java Applications (Page last updated November 2005, Added 2005-11-29, Author Michael Nash, Publisher developer.com). Tips:

• In addition to trying to code around fatal errors, you should also make the application auto-restarting.
• An application should be able to be spread across multiple machines.
• Each physical software layer of an application needs to be clustered (& distributed) separately so that there is no single point of failure.
• Open-source solutions such as C-JDBC and HA-JDBC can take your single database and turn it into a cluster of databases.
• Both C-JDBC and HA-JDBC distribute "read" operations among the cluster of databases, directing the next read to the least loaded DB in the cluster. Writes are done to each database, ensuring they remain synchronized.
• Messaging (e.g using JMS) provides automatic failover and some load-balancing too by taking advantage of distibuted queues.
• Applications should be configured to run with multiple JMS brokers so that they can failover automatically if the "current" JMS broker dies.

Jack Shirazi Back to newsletter 060 contents