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 048 contents

http://www-106.ibm.com/developerworks/library/j-jtp10264/
More flexible, scalable locking in JDK 5.0 (Page last updated October 2004, Added 2004-11-30, Author Brian Goetz, Publisher IBM). Tips:

• ReentrantLock class in java.util.concurrent.lock has the same memory semantics as synchronized, the same locking semantics, better performance under contention, and features not offered by synchronized like like lock polling, timed lock waits, and interruptible lock waits.
• synchronized means that only one thread at a time can execute code protected by a given monitor object (lock), allowing you to prevent multiple threads from colliding with each other when updating shared state.
• synchronization ensures that updates to variables made by one thread prior to exiting a synchronized block will become immediately visible to another thread when it enters a synchronized block protected by that same monitor (similar to volatile variables).
• Whenever you will be writing a variable that may next be read by another thread, or reading a variable that may have last been written by another thread, you must synchronize.
• ReentrantLock has far better performance than synchronized under heavy contention. When many threads are all contending for the same lock, the total throughput is generally going to be better with ReentrantLock than with synchronized.
• Forgetting to release a ReentrantLock in a finally block can create a time bomb in your program whose source you will have a hard time tracking down when it finally blows up on you. ReentrantLock locking and unlocking is your responsibility, synchronized locking and unlocking is the JVMs responsibility.
• The Lock framework includes a generalization of wait and notify called Condition. synchronized has a single wait condition associated with a monitor; Conditions allows more than one wait condition to be associated with a lock.
• ReentrantLocks can be fair (threads acquire locks in the same order they ask for it) or unfair (no guarantee of ordering). The bookkeeping and synchronization required to ensure fairness mean that contended fair locks will have much lower throughput than unfair locks. synchronized locks are unfair.
• For ReentrantLocks you should set fair to false unless it is critical to the correctness of your algorithm that threads be serviced in exactly the order they queued up.
• The vast majority of synchronized blocks hardly ever exhibit any contention.

http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
Multithreaded toolkits don't work (Page last updated October 2004, Added 2004-11-30, Author Graham Hamilton, Publisher java.net). Tips:

• There seems to be an amazing tendency towards deadlocks and race conditions in multithreaded GUIs.
• GUIs present two different kinds of activities, input and output, that want to acquire locks in opposite orders. So deadlock is almost inevitable if you multithread those activities.

http://weblogs.java.net/blog/joshy/archive/2004/10/please_think_of.html
User interfaces (Page last updated October 2004, Added 2004-11-30, Author Joshua Marinacci, Publisher java.net). Tips:

• Software that doesn't conform to the way humans do things is bad software [has bad performance perception too].
• Leave your software for a while (a day or more) and then come back and run it - this can give instant complexity feedback.

http://blogs.msdn.com/ricom/archive/2004/10/25/247423.aspx
Performance tidbits for library writers (Page last updated October 2004, Added 2004-11-30, Author Rico Mariani, Publisher Mariani). Tips:

• Library operations can be called very frequently, so must be very careful in their performance costs.
• Hashing and object comparison should scale linearly - O(n).
• Avoid allocating temporary memory in library functions.
• Good parsers make exactly one pass over their inputs and create no, or virtually no, temporary objects in the course of parsing.
• You're not done with your implementation until you've measured its performance.

http://java.sun.com/developer/community/chat/JavaLive/2004/jl1012.html
New Language features in J2SE 5.0 (Page last October 2004, Added 2004-11-30, Author Scott Seligman, Peter von der Ah?, Edward Ort, Publisher Sun). Tips:

• Generics are dealt with (almost) entirely at compile-time and impose no performance impact, neither better nor worse.
• Doing the boxing yourself rather than autoboxing you can probably be more efficient than the compiler.
• Don't worry about autoboxing performance unless you have profiled your application and discovered a bottleneck.
• Autoboxing can cause a large number of small objects to be created, which can impact performance negatively.

http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html
Local and Remote EJB Interfaces (Page last updated November 2004, Added 2004-11-30, Author Olexiy Prohorenko, Publisher OnJava). Tips:

• An EJB can use local client view only if it is really guaranteed that other enterprise beans or clients will only address the bean within a single JVM. If this is the case, such access will be carried out with direct method calls, instead of RMI.
• Enterprise beans that are tightly coupled logically are good candidates for using local client view.
• Creating a remote object (if it does not exist yet) requires creating a stub and a skeleton, which will cost cycles.
• Transferring primitive data types is more efficient than transferring complex data types, such as Collections.
• Returning a remote object is somewhat expensive, taking time to transfer the object to the client and create copies.

Jack Shirazi Back to newsletter 048 contents