Yesterday I attended Brian Goetz' Effective Concurrency For Java and today I went to the companion session Testing Concurrent Java. Both build on topics from Brian's excellent book, Java Concurrency in Practice, which first went on sale one year ago, right here at JavaOne.

Listening to these two sessions and chatting with a few folks here at the show, I'm more convinced than ever that concurrency is a looming problem that is, for the most part, going unrecognized.

As Brian pointed out, CPU speeds are leveling off. CPUs are not getting faster, they're getting fatter. In a matter of about a year, dual core CPUs have become the norm. I'm typing this right now on a dual core MacBook Pro. Quad core is becoming a reality in pro-sumer systems and sixteen core servers are not uncommon.

This sea change in the hardware space has many implications for we Java programmers. The first is the obvious one, that Java coders are going to have to get more sophisticated about concurrent techniques to get the most out of the runtime environments they will find themselves in.

But there's a flip side - a darker side, perhaps. A correct, single-threaded program will run fine on a multi-core machine, making use of only one CPU core at a time. But many single-threaded programs out there harbor undiagnosed concurrency bugs that never, or rarely manifest on single core CPUs. Here's a hint: finalizers are evil.

And then there are Java programs that are using multiple threads without well thought out locking strategies (or sometimes none at all!). On single core systems a tiny little race condition may never cause a problem. With more cores, more threads truly run in parallel, and more concurrency problems will come to light.

More cores means more broken code. Have you planned for it? Have you even thought about it? Will your code run properly under load on a system with 256 cores? Something to think about.