Back to newsletter 073 contents

http://cretesoft.com/archive/newsletter.do?issue=134&locale=en_US
DRY Performance (Page last updated October 2006, Added 2006-12-28, Author Kirk Pepperdine, Publisher The Java Specialists' Newsletter). Tips:

• Good design is essential to help achieve good performance.
• There is a widespread myth that you need to sacrifice good design or write overly complex code in order to achieve good performance.
• The Don't Repeat Yourself (DRY) design principle is an excellent match for ensuring good performance - using this principle, instead of common operations that are bottlenecks being scattered throughout code, diluting or hiding their effect, the operation is in one place making it clear where the bottleneck is, and additionally making it much simpler to tune instead of having to trawl through the code looking for every instance of that operation.
• In the absense of the Don't Repeat Yourself (DRY) principle, changes to a particular operation can be applied inconsistently across the code, and tuned code can lose the optimizations in some places and not others, both adding complexity and reducing performance.
• [Article works through a tuning exercise that shows how the Don't Repeat Yourself (DRY) principle helps performance tuning].
• Replacing direct use of String with more appropriate performance tuned optimized wrapper or replacement classes is a good optimization in many cases.

http://www.artima.com/weblogs/viewpost.jsp?thread=182203
Distributing synchronization across threads (Page last updated October 2006, Added 2006-12-28, Author Gregg Wonderly, Publisher Artima). Tips:

• Change any long-lived locks to multiple short-lived ones by altering the code so that only those operations that need to be locked are locked, probably by using one or more locks which could be different from the original lock.
• java.util.concurrent.ConcurrentHashMap is a fast thread-safe Map implementation which can resolve some concurrency issues with minimal locking.
• FutureTask provides a nice way to associate a lock with something that provides access to the needed object.
• It looks like they finally fixed java.sql.DriverManager in JSE-6 so that getConnection() is no longer synchronized. In applications using lots of different databases, if one was down, and something was trying to connect to it, all the other database connections would hang on entry to getConnection() until the TCP connect timed out.

http://radio.javaranch.com/weitzman/2005/08/03/1123093745052.html
StringBuffer.toString() doesn't share contents in 1.5 (Page last updated August 2005, Added 2006-12-28, Author David Weitzman, Publisher JavaRanch). Tips:

• StringBuffer no longer shares its contents with the Strings it creates in 1.5 (probably because of the gotcha of potential massive memory leaks from the unexpected link)
• It is often more efficient to reuse a StringBuffer or StringBuilder to make similar strings.

http://weblogs.java.net/blog/richunger/archive/2006/09/debugging_permg.html
Debugging PermGen OutOfMemoryError problems in windows (Page last updated September 2006, Added 2006-12-28, Author Rich Unger, Publisher java.net). Tips:

• Use jmap to see what's in PermGen space.
• Until jdk6, jmap wasn't available on windows, and even in jdk6, the windows version doesn't support the -permspace flag.
• jconsole monitor the JVM's MBeans graphically including all JVM memory spaces (in 1.5 you need to launch your VM with the -Dcom.sun.management.jmxremote flag, in 1.6 they are on by default).
• You can use the jconsole from the 1.6 distribution (has a better interface than the 1.5 jconsole) to monior 1.5 JVMs with no problems.

http://www.javaworld.com/javaworld/jw-11-2006/jw-1121-thread.html
Hyper-threaded Java (Page last updated November 2006, Added 2006-12-28, Author Randall Scarberry, Publisher ). Tips:

• Increasingly programs need to be multithreaded to fully utilize a computer - soon, single-processor, single-core systems will be considered relics.
• You won't inherit the advantages of simultaneous multithreading automatically unless your application is already implemented to use multithreaded algorithms.
• Move a single-threaded application to a multithreaded implementation by: Identify the subtasks in your application; identify the subtasks that bottleneck the application (benchmark or profile); Delegate the most time-consuming subtasks to a thread pool.
• ThreadPoolExecutor may be configured with either a variable or a fixed number of threads. The threads may be configured to time out if not given a task for a sufficient length of time.
• When a multithreaded operation is being performed by the pool's threads, the controlling thread needs to know when the operation has finished. A CyclicBarrier instance informs the controlling thread when an operation is complete, so the controlling thread knows when to proceed.
• [The article steps through a real-world example of converting a single-threaded application to use multiple threads].

http://www.ddj.com/dept/java/191601642
Multithreading, Java, & OSGi (Page last updated August 2006, Added 2006-12-28, Author Oliver Goldman, Publisher Dr Dobbs). Tips:

• A relatively modest amount of reusable code can go a long way toward easing multithreaded programming.
• The basic pattern for controlling threads is: Keep track of each thread when you start it (Thread.start()) ; Know how to interrupt each thread (Thread.interrupt() & variations); Wait for each thread to exit when stopping (Thread.join()).
• Thread.interrupt() only interrupts threads waiting on monitors. It will do nothing for a thread blocked on, say, reading from an InputStream.
• To ensure threads can be interrupted, the article suggests using an abstract class, Interruptible, which extends the standard Java Runnable interface with an interrupt() method, and an associated ThreadManager with two basic operations: run( Interruptible ) and stopAll() . The Interruptible.interrupt() method has to know with certainty how to interrupt each thread.
• To ensure an operation will occur when any thread exits, wrap the thread in another Thread/Runnable class which wraps the call to Runnable.run() in a try/finally block. The finally clause is invoked when run() returns - whether normally or with an exception.
• To interrupt the UI thread (SWT): launch a thread on which a loop polls and processes the event queue. The interrupt method for this thread uses the SWT Display.asyncExec() call to post a "quit" event back to the UI thread, causing that loop to exit. Swing provides similar facilities.
• To interrupt threads waiting on I/O: close the stream or socket on which they are waiting. The close will cause the read(), accept(), or other call to return with an error.
• Worker threads performing computation can be the trickiest to interrupt because there is not a good mechanism for interrupting CPU-bound work from another thread. The best option here is to have the thread periodically check to see if an interrupt bit has been set. It shouldn't do that too often or the overhead will take a toll, but it must do it frequently enough to keep the interrupt responsive. [Note Thread.stop would also work, but you shouldn't use that unless you are aware of the consequences].
• Adding interruptibility to signatures hints at potentially big requirement changes for those writing reusable code.
• InterruptedException must be obeyed - not ignored. The exception is thrown when an operation should exit immediately. Ignoring it is almost certainly the wrong thing to do.

Jack Shirazi Back to newsletter 073 contents