问题
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 and sets of custom scripts for managing these JVMs. This setup is really showing its age at this point: managing that many JVMs is becoming a monitoring/management nightmare and we are constantly dealing with heap sizing issues. We'd like to move to a more modern approach and just run a bunch of applications in a single app server per physical machine. However, keeping the applications separate does have distinct advantages in terms of isolation (e.g. out of memory errors only affect one customer). Each customer's software stack has memory requirements that vary widely.
My question: is there a way to have the best of both worlds here and run multiple applications in one JVM (app server) and still maintain some level of isolation? Or is it just a modern fact of life that you need to manage memory requirements of a set of applications these days? Are there other solutions here besides an app server or Java EE container (e.g. Wildfly or Spring) that I'm missing here? It seems like this system is a holdout from another era!
回答1:
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).
回答2:
There's pros and cons of either approach:
Shared JVM
- Lower overhead - JVM memory footprint (core libraries etc.) only needs to be loaded once.
- Better memory usage. Java processes will consume OS memory for heap space that may not currently be in use.
Separate JVM
- Insulation from 'greedy' or 'leaky' applications.
- Better security from malicious code.
- Easier updates, updating one app without bringing down the other.
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.
回答3:
Have a look Spring Boot or Fabric8 for a modern take on running Java in a manageable way
回答4:
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.
来源：https://stackoverflow.com/questions/26145408/multiple-jvms-vs-single-app-server