Of course, no technology can change the laws of physics, so if all your threads are truly contending for one resource, they will have to be serialised.
However, if the threads are contending for a java lock AND it turns out that they would not actually corrupt data each other is looking at (i.e the java lock is very coarse grained, but the data accessed within it is fine grained) then the Azul appliance can help because its "Speculative Multiaddress Atomicity" feature allows optimistic locking to take place, as mentioned in the article.
(see 'Optimistic Thread Concurrency' here: http://www.azulsystems.com/products/cpools_tech.html )

WebLogic Performance: Pursuit of Speed Isn't Everything. 'High performance' is what everybody strives for when putting together a new system. Technical folk often spend hours hung up on the raw speed of their code, and a certain machismo can be derived from shaving milliseconds off that pesky transaction that is the latest pride and joy. Often, this time is not very well spent.

||| on a typical server, those 60 execute threads you configured for WebLogic are probably being executed across a handful of CPUs at the most |||

What about when contention occcurs?