Angelika Langer has a talk about multi threaded programming in a multi processor environment.
Due to CPU developments new issues arise in current applications when newer CPUs are used. The JVM now has more and more functionality to support multithreaded/multicore environment. The java.concurrent package. Available since java 5.
The new CPUs demand a-synchronous approach. Therefor the java NIO api was born. In java 7 they are planning for a-sync file io.
JMS is a result of the need for a-sync operation.
Ajax results in more and longer running network operations. Long lived http requests results in more overhead in the io layer of the server.
The java memory model is an abstraction of the underlying hardware memory models. It addresses atomicity, visibility and ordering. Angelika details some examples.
So far a very high level overview.
Sequential consistency does not exist in the JVM. It’s a mental model used to teach multithreaded programming, it is not guaranteed by the JVM. You have to use language construct to enforce proper visibility. Synchronisation ensures proper execution order and prevent trashing half written objects and variables. To ensure a proper execution it is required that you force updating main memory by using the volatile keyword.
Visibility is ensured when using explicit synchronisation, thread start and termination, read/writes of volatiles and first access of a final field.
Volatile is not transitive, it is only applicable for the reference marked as volatile. She shows an example of the non volatile field. But since Java 6 there are some changes to the memory model. Changes to members of a volatile reference are propagated when they’re performed before modifying the volatile reference itself. Complicated stuff that breaks easily.
Volatile is cheaper then synchronisation, but still there’s a cost.
Amdahl’s law. Look it up, good stuff. Double the hardware will not double the performance. It depends on the amount of parallel execution paths.
It is an easy trap to think that having a queue for inter process communication will not contain blocking behaviour. Try to have the absolute minimum of synchronous code if performance is key.
There are techniques to avoid serialisation. Use immutable copies, use thread local objects instead of shared objects. Lock free programming gaining popularity, volatile declaration is still required though. Compare and Swap is an example of a technique to allow lock free programming. There are some things on the horizon, like transactional memory.