I\'m dealing with a system that runs a Java application per customer in its own JVM. We\'ve got about a half dozen dedicated servers that are running close to 100 JVMs total now
Checkout 'multi-tenant' JVM's.
IBM's JRE has it already: http://www.ibm.com/developerworks/library/j-multitenant-java/
Waratek has implemented it on top of the Oracle JRE, and they created ElastiCat, a Tomcat fork that isolates different applications in the same container: http://www.elasticat.com/faq/
Multi-tenancy is rumoured to appear in the official Oracle Java 9 JVM, too.
=======================================================
Update: Java 9 is out, but no word from Oracle about multi-tenancy. It seems they prefer having multiple JVM's these days, even multiple Containers (e.g. docker).
There's pros and cons of either approach:
Shared JVM
Separate JVM
Overall, I wouldn't set a blanket policy. Look for small / micro-services or other low-usage apps that may be good candidates to share first and expand from there.
Have a look Spring Boot or Fabric8 for a modern take on running Java in a manageable way
Another important reason to have multiple JVM instead of one is when facing numa groups. You cannot distribute your threads within one JVM appropriate over numa groups as you can with multiple jvm processes. At least i never found a way to do so.
We have here machines with two cpu's, each having 18 cores, This gives two numa groups and we cannot enforce 34 Threads to be spread upon both cpu if only one JVM is used. This is obviously because it assumes that all threads of the same JVM process need to have fast access to the same memory which is not the case.
Having 34 Processes the system assumes they have no need for shared memory and thus spread them over both cpus.
If someone knows a better way of doing this i would be very glad to hear it.