This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
I couldn't quite get a clear picture of what you're looking for, but maybe this will help:
The technical name for scheduling more work on a computer than it can handle is "overcommit". Overcommitting was fairly common back when expensive mainframes were the rule, but these days hardware is so cheap that the usual response to a heavier workload is to just buy more hardware.
However, sometimes that's not sufficient and even after tuning you may still end up overcommitted.
Once that occurs, it's time to sit down and determine who's going to get the short end of the deal. Since resources are finite, then next best thing is to give them to those who can best justify their use - meaning produce more revenue, keep everyone out of trouble, or just plain have the political pull. You then draw up service level agreements that specify how much of the pie each consumer is going to get and what the rules on dividing the pie are going to be.
The original Unix solution for that was in programs like "nice" that maintained a set of CPU dispatcher priority levels. You would mostly adjust the nice levels yourself on a manual basis.
That's only the start, however. On a heavily-used system, you have queues for more than just CPU time, you may also want to load-balance on network and disk resources. Also on how much real memory will back up each process versus how much virtual memory it consumes.
The big-league vendors like IBM and Sun have very elaborate resource management systems. They would allocate general service levels, dynamically bump resources up and down in response to changing conditions - for example, the longer a processs ran, the lower priority it might be given - and do whatever else was necessary. In one IBM shop I worked in, we'd even switch the service level rules 3 times a day as we went from day shift (online users and developers) to night shift (production processing) to early-morning shift (backups and system maintenance).
Ultimately, Java apps are native code as well. The JVM is native code and so is any JIT- or pre-compiled Java code. From the OS's point of view, it's just another native app. Of course, every app has its own ways of using resources. So for optimal performance, you'll want to set some service levels and investigate the load-balancing options that the system(s) you're running on support.
Customer surveys are for companies who didn't pay proper attention to begin with.