This is a question as much as a discussion, I can’t find a lot of detail on the state of play in this area and would really welcome any feedback or corrections. Please don’t read this as a negative article as that is not how it is intended; it’s in the optimisation section but I’m not sure what impact it really has. One thing for sure, for 99% of systems you probably don’t have to worry about what’s going on here at all.

Recently I started to wonder how Garbage collection events in large heaps affect cache performance. Earlier today I read an interesting article on the mechanical sympathy blog (Mechanical Sympathy: CPU flushing article ) about the way processor caches work, and it re-enforced a feeling I’ve had for a while; that old generation GC’s on very large heaps could cause a lot of cache misses because each object in the generation has to be marked and swept. This led to more searches where I dug up this page on stack overflow (Stack Exchange: is GC cache friendly).

Over the years there have been no shortage of ways to format a string in java. What with the + operator, StringBuffer, StringBuilder, String.format(..) and various specialised formatters for numbers and dates we sometimes feel a little spoilt for choice. But how do they all work and what are their advantanges / disadvantages?

There are several ways to format dates in Java, but by far the easiest is to use DateFormat. Creating a DateFormat is very similar to NumberFormat that we saw on the previous page. Here are the static factory methods called directly on the DateFormat class:

Firstly, an instance of CountDownLatch is instantiated passing to the constructor the number of times that the latch must count down before going into the latched state. By latched state we mean the state in which await will no longer block. In our example we need to wait for a thread to initialise before proceeding. We achieve this by creating a count down latch with a count of 1. Once the thread has done its work, it calls countDown on the latch. In the mean time the main thread has continued to do its longJob and then called await on the CountDownLatch instance. Calling await blocks until countDown has been called enough times (in this case once).

Although tomcat takes care of authenticating users at the right time, there are still times when we need to programatically access the credential information. For example the following snippet from userProfile.jsp is a mixed mode page In that anyone can view the page, but some users with manager role see more information.

To do this we use a method on the request object. request.isUserInRole(roleName);.Below is an example of its usage from the userProfile page.

Up to now we have been using the inbuilt memory realm. This is great for testing but in any real application is would probably not be acceptable. Normally user credentials are stored in a database, so for this purpose there is a realm based on a datasource.

Depending on your view of things, you will either edit server.xml in the tomcat-home/conf directory, or you will edit the context file for the specific application. There are a few choices here, all of which are explained in the tomcat 7.0 documentation. For the purpose of this article we will edit server.xml.

In this example I show an usage of two more concurrent classes CyclicBarrier and Semaphore; which are both provided in the core Java library. There's a wealth of concurrency classes built directly into the JVM that can really simplify multi-threaded development.

In this entry I show how to use the inbuilt Java XMLStreamReader PULL parser class to read an XML file. The XML stream libraries are PULL based XML parsers that do not load the whole document into a memory structure, so therefore are more suited to large volumes of XML.

Below is an example XML file for a zoo, it contains Animal data types that have both attributes and data. It is kept simple for the sake of example. To run the example, copy this XML into the ROOT of your classpath.

In this BlockingQueue example we show how to write a very simple producer - consumer with a blocking queue. This example generates SimpleAddition objects that require an addition of two numbers to be performed on the consumer thread. In this case the two values to be added are generated using java.util.Random's nextInt call. They are stored on the queue as a SimpleAddition transfer object and picked up for processing on the consumer thread.

We make the queue smaller than the number of items to be processed, so it is probable that we will need to block while producing, as the call to put may block.

In this article I show an example of creating a bar chart with a fixed colour. This was missing from the groovychart example set, and will get included into the next build. If you are unfamiliar with groovy chart then here is an introduction to Groovychart.

We simply tell the plot's renderer to use the StandardBarPainter. This turns off the gradient paint that is used by default.


This area of the website discusses JVM optimisation and analysis techniques. This subject tends to trigger quite strong reactions in people, and it's not unusual for there to be many differing opinions on this subject.

My aim is to provide articles that are based on evidence and follow best practice.