Bhaskar Sunkara had the guts to publish "Three Common Application Performance Challenges for Developers" on DZone. The ones he covers are: memory leaks, slow SQL, and thread synchronization. Same story, different day: none of these are surprising but people haven't gotten the message.
Memory management is the same old chestnut about not leaking object references. He points out that heap dumps and profilers can help you track them, but in production, it's harder to find leaks; he points out transaction and code path analysis as a way to help find these, but doesn't mention products like JXInsight or dynaTrace, which exist for this exact purpose (tracing performance issues in production environments without killing performance.)
Slow SQL is his next point, and he says that indexes and too much data being fetched are major problems. Then he says that an ORM stands out to kill performance. He contradicts himself a little here, to me, because pointing out an ORM as a performance problem isn't the same as blaming a stupid DBA for setting up tables wrong or blaming a dumb developer for retrieving too much data or, issuing too many SQL calls.
The main thing to get from this, though, and he's right, is that getting data can be slow. Use Ehcache or memcached to save data, if you can, although ehcache and company add extra code to your reads and writes. Also, factor in network time to your database calls.
The last thing he covers: threads. He doesn't really give advice here, partly because the subject's not simple, I guess; he mentiones Software Transactional Memory Systems, which I don't really understand, and doesn't mention Java Concurrency in Practice. I think Azul Systems uses something like this, but I don't know how.
Interesting article. It's sort of the same old stuff, we see stuff like this all the time. But at the same time, we see Java developers who don't seem to be aware of it, so the the signal has to be repeated. You can't stop the signal, Mal.