Back to newsletter 104 contents

http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html
A Beautiful Race Condition (Page last updated June 2009, Added 2009-07-23, Author Paul Tyma, Publisher Malinator). Tips:

• Don't use HashMap for any type of concurrent access - article provides a detailed run through why you should avoid this.
• Concurrent updates to HashMap can cause a corrupt structure that leads to an infinite loop. Use ConcurrentHashMap as your default Map.

http://kirk.blog-city.com/continuous_performance_testing.htm
Continuous Performance Testing (Page last updated June 2009, Added 2009-07-23, Author Kirk Pepperdine, Publisher pepperdine). Tips:

• Industry has learned the hard way that holding a big testfest at the end of the development phase of a project is a great way to ensure failure - this applies equally to performance testing.
• Avoiding premature optimizations has been confused by some as avoiding performance aspects of a project altogether, only focusing on it when it becomes necessary - this is wrong. You need to consider performance at all stages, or you are setting yourself up for failure or much more work later on.
• During requirements gathering phase you need to collect users expectations for performance.
• During architecture defining, you should use benchmarking to determine that your decisions will not prevent your architecture from meeting your performance goals.
• During development you should integrate Continuous Performance Testing to your system so that you can gain an understanding of how your system is progressing.
• Performance testing at unit test level (i.e. method level) isn't completely wrong, but is a level of granularity that isn't advisable.
• Performance testing during development should be done at an appropriate level of granularity: at the component level, or possibly at the class level for some types of classes.

http://www.artima.com/forums/flat.jsp?forum=270&thread=262541
Laurence Vanhelsuwé on Java Collections Pitfalls (Page last updated July 2009, Added 2009-07-23, Author Frank Sommers, Publisher Artima). Tips:

• Objects with hashCode() implementations that uses mutable object state can produce a corrupt Map if you use such objects as Map keys. For example HashMap.get() can turn into an infinite loop if the HashMap gets corrupt.
• Hashcodes that aren't distributed appropriately will result in hash tables that have terrible performance.
• If you have a non thread-safe container such as HashMap being accessed by several threads, that's an indication that you need to take a closer look at how and when that container is accessed.

http://jeremymanson.blogspot.com/2009/06/volatile-arrays-in-java.html
Volatile Arrays in Java (Page last updated June 2009, Added 2009-07-23, Author Jeremy Manson, Publisher jeremymanson). Tips:

• If you write to a volatile field and then you have a later read that sees that write, then the actions that happened before that write are guaranteed to be ordered before and visible to the actions that happen after the read.
• The elements of an array are not volatile, only the array pointer itself is. So defining an array as volatile does not provide you with an array of volatile elements.
• Use Atomic[Reference/Long/Integer]Array in java.util.concurrent.atomic if you want the semantics of an array of volatile elements

http://java.dzone.com/articles/hibernate-performance-tuning
Hibernate Performance Tuning (Page last updated June 2009, Added 2009-07-23, Author Ming Jiang, Publisher JavaLobby). Tips:

• Use prepared statements with placeholder values (e.g. 'where user.name =?') rather than dynamic SQL.
• Configure properties like hibernate.jdbc.fetch_size, hibernate.jdbc.batch_size and switch off the SQL output by setting hibernate.show_sql to false in product environments.
• Manage the Session efficiently by using ThreadLocal for a thread local copy of the session for every thread.
• Set the property hibernate.cache.user_query_cache = true if doing any caching
• To clear an object from the session use: session.evict(object). To clear all the objects from the session use session.clear().
• You can specify a caching class by setting the property hibernate.cache.provider_class to e.g. Hashtable/EHCache/OSCache/SwarmCache/JBoss TreeCache/Terracota

http://www.developer.com/java/article.php/3829891
Selecting the Best Java Collection Class for Your Application (Page last updated July 2009, Added 2009-07-23, Author Mark Grand, Publisher Developer.com). Tips:

• All Vector methods are synchronized as are Stack methods.
• ArrayList fast operations are getting the size of the list, getting the object at a specified position in the list, and setting the object at a specified position in the list.
• LinkedList can quickly insert or remove objects in the middle of the list whereas ArrayList takes time proportionate to the number of objects in the list after the position to which objects being added or removed. Use ArrayList unless you are inserting or deleting a lot from the middle of a list.
• If you rarely iterate an ArrayList object while it is being modified, then using a lock is a good solution. However, if iterating over a ArrayList while modifying it is common, then locking may make waiting time unacceptably high.
• With CopyOnWriteArrayList all operations that change the contents of a CopyOnWriteArrayList collection cause the underlying array to be replaced with a copy of itself before the contents of the array are changed. Any active iterators will continue to see the unmodified array, so there is no need for locks.
• HashSet is faster than TreeSet, so only use the TreeSet preferentially when you need elements to remain in sorted order.
• HashSet is faster than LinkedHashSet so only use the LinkedHashSet preferentially when you need elements to remain in insertion order.
• ConcurrentSkipListSet keeps it's elements in sorted order and is thread-safe and usually preferable to a synchronized wrapped set.
• With CopyOnWriteArraySet all operations that change the contents of a CopyOnWriteArraySet collection cause the underlying array to be replaced with a copy of itself before the contents of the array are changed. Any active iterators will continue to see the unmodified array, so there is no need for locks.
• PriorityQueue add and remove methods take time that is proportionate to the number of objects in the queue. Queues based on the PriorityQueue class do not block. PriorityBlockingQueue is similar in performance but does block.
• For situations when multiple threads are waiting to perform operations on a queue, the behavior of an ArrayBlockingQueue object will be more consistent and predictable than for a LinkedBlockingQueue.
• ConcurrentLinkedQueue is thread-safe and usually preferable to a synchronized wrapped queue.
• DelayQueue is a specialized blocking queue that consults the objects it contains as to when they can be removed from the queue.
• A SynchronousQueue object is always empty; the put method blocks unless another thread is waiting for the object's take method to return.
• If you are not interested in how objects will be organized in a collection, then the only other consideration is performance. In that case, use the ArrayList class. It is fast and makes efficient use of memory.

Jack Shirazi Back to newsletter 104 contents