There seems to be a lot of fuss about multicore and java. While some people say that java support is not good enough, it definitely seems to be an area to look forward to. There seems to be many techniques to improve performance of concurrent programs.
Any tips/advices about programming in a multi core scenario is appreciated.
Look into the new Java concurrency facilities (in the java.util.concurrent package) which have been added in Java 5. It provides functionality that is more high-level than regular Threads which will make it easier (and less error-prone) to write concurrent applications. The Lesson: Concurrency of The Java Tutorials would be a good place to start.
So far, I've only used the ExecutorService, which allows can produce thread pools, to which new tasks can be handed off in units of Runnables or Callables (which can return values after execution as Futures), and the actual threading code is handled by the ExecutorService.
For example, performing some calculation using a thread pool of 2 threads, and getting the result can be as simple as:
ExecutorService es = Executors.newFixedThreadPool(2);
Future f1 = es.submit(new Callable<Integer>() {
public Integer call()
{
// Do some processing...
return someInteger;
}
});
Future f2 = es.submit(new Callable<Integer>() {
public Integer call()
{
// Do some processing...
return someInteger;
}
});
Integer firstInteger = f1.get();
Integer secondInteger = f2.get();
In the above (untested) code, all I have to worry about is making a couple of Callables and submiting it to the ExecutorService and later on, using the Futures to retrieve the result.
The catch is, once the get method of the Future is called, if the processing isn't complete, the program will stop until the result of the Future can be retrieved. So, in this example, even if the result of f2 is available before f1, the program will wait until the result of f1 is available.
In terms of reading material, on my list of books to purchase soon is Java Concurrency in Practice by Brian Goetz, which comes up often when concurrency in Java is brought up.
The Concurrency Utilities page from the Java 5 documentation has more information as well.
Always a good tip - if most of your classes are immutable everything becomes so much easier as immutability removes the need to worry about locks from many to few places of concern.
The best tip has got to be: get your synchronization correct!
This may seem somewhat obvious but an understanding of the Java Memory Model is vital, particularly how volatile and final fields work, how synchronized acts as both a mutex and a memory barrier and then the new java.util.concurrent constructs as well
Check out Brian Goetz's talk From concurrent to Parallel from Devoxx 2008. Not many tips there, but it gives you an idea where Java concurrency is heading to.
The best book with practical tips has been Java Concurrency in Practise. It is a must read for all java programmers, even those who thinks they dont do any concurrent programming, because java has many hidden threading in its various libraries (swing comes to mind, same with servlets).
Check out the forthcoming fork-join framework. The fork-join framework enables developers to achieve fine-grained parallelism on multicore architectures.
Also you may want to check out JVM based languages like Clojure that claim to make multicore parallel programming easier.
As an alternative to Java's own shared-memory approach to concurrency you could also look into Actor-based concurrency using Scala on top of Java, which provides an easier model for concurrent programming.
My tip: Understand the Java Memory Model (since JDK 5 and higher). Most people do not know, that synchronization, volatile, and final have an additional meaning beyond the normal multi-threading scope.
Java is fine for multi-cpu and multi-cores. If you program it right and you invest some brain, you get a highly concurrent server system to utilize 8-cores including a lot of synchronization and so on. We are quite happy with it... JDK6 is better than JDK5 and everything below sucks on multi-cpu machines.