90

A JVM runs in a single process and threads in a JVM share the heap belonging to that process. Then how does JVM make use of multiple cores which provide multiple OS threads for high concurrency?

Andrii Abramov
  • 10,019
  • 9
  • 74
  • 96
Munish Sodhi
  • 909
  • 1
  • 7
  • 3
  • 6
    As far as I'm aware, Java threads are native OS threads (in most JVMs). Nothing special about them. – Sasha Chedygov Dec 14 '10 at 06:17
  • 5
    Native application threads also run in a single process and share a common memory allocation (and can still make use of multiple cores). – Thilo Dec 14 '10 at 06:23

4 Answers4

38

You can make use of multiple cores using multiple threads. But using a higher number of threads than the number of cores present in a machine can simply be a waste of resources. You can use availableProcessors() to get the number of cores.

In Java 7 there is fork/join framework to make use of multiple cores.

Related Questions:

Community
  • 1
  • 1
Emil
  • 13,577
  • 18
  • 69
  • 108
  • 6
    Machines usually have only 2 or 4 processors. You stated that "using a higher number of threads than the number of cores present in a machine can simply be a waste of resources", does that mean that we should have around only 2 or 4 threads to maximize performance? – Pacerier Sep 23 '14 at 07:31
  • 5
    "But using a higher number of threads than the number of cores present in a machine can simply be a waste of resources." That doesn't make a whole lot of sense in the general case. If you have more threads than the number of cores the threads would be distributed across those cores and would get their share of the given core just like any other running thread/process thereby allowing it to make progress which would definitely be more efficient than doing the work sequentially. – ChiefTwoPencils Sep 23 '16 at 20:08
  • @ ChiefTwoPencils; If we have two applications and each application has 6 threads running on 4 CPU cores. In this case how tasks will distributed across these CPUs? Another question in a single application 6 threads are running on 4 CPUs will all 6 threads parallely running across these 4 CPUs or interleaving operations across thread – user3094331 Jun 18 '20 at 02:38
  • Is it true, that if you run a web application on Tomcat (on Java 8 for instance) where each incoming HTTP requests is processed by a Java-Thread, web apps therefore automatically benefit from multiple cores, right? Today you can rent 32-core AMD machines which sound perfect to me to run a web app. Sure: cloud is another option, but I'm talking about dedicated servers now... Any comments? – basZero Aug 27 '20 at 12:14
36

A JVM runs in a single process and threads in a JVM share the heap belonging to that process. Then how does JVM make use of multiple cores which provide multiple OS threads for high concurrency?

Java will utilize the underlying OS threads to do the actual job of executing the code on different CPUs, if running on a multi-CPU machine. When each Java thread is started, it creates an associated OS thread and the OS is responsible for scheduling, etc.. The JVM certain does some management and tracking of the thread and Java language constructs like volatile, synchronized, notify(), wait(), etc. all affect the run status of the OS thread.

A JVM runs in a single process and threads in a JVM share the heap belonging to that process.

JVM doesn't necessary "run in a single process" because even the garbage collector and other JVM code run in different threads and the OS often represents these different threads as different processes. In Linux, for example, the single process you see in the process list is often masquerading a bunch of different thread processes. This is even if you are on a single core machine.

However, you are correct that they all share the same heap space. They actually share the same entire memory space which means code, interned strings, stack space, etc..

Then how does JVM make use of multiple cores which provide multiple OS threads for high concurrency?

Threads get their performance improvements from a couple of reasons. Obviously straight concurrency often makes the program run faster. Being able to do multiple CPU tasks at the same time can (though not always) improve the throughput of the application. You are also able to isolate IO operations to a single thread meaning that other threads can be running while a thread is waiting on IO (read/write to disk/network, etc.).

But in terms of memory, threads get a lot of their performance improvements because of local per-CPU cached memory. When a thread runs on a CPU, the local high speed memory cache for the CPU helps the thread isolate storage requests locally without having to spend the time to read or write to central memory. This is why volatile and synchronized calls include memory synchronization constructs because the cache memory has to be flushed to main memory or invalidated when threads need to coordinate their work or communicate with each other.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • 1
    Thank you for this answer - but I have a request: It would be really helpful if you could prefix "OS" or "Java" before each use of the word "thread". The clash of terms is terribly confusing to me (and I'd guess some others too) and I'd be lying if I said I really understood the whole thing now. – Niki Herl Jan 14 '20 at 18:52
  • 3
    The whole point here @NikiHerl is that the Java threads have OS thread equivalents. If I'm not specifying the type of thread then it doesn't matter. For example, when I talk about isolating IO to a single thread, that is for both the JVM thread and the OS thread which is doing the work. – Gray Jan 17 '20 at 21:19
25

Java will benefit from multiple cores, if the OS distribute threads over the available processors. JVM itself do not do anything special to get its threads scheduled evenly across multiple cores. A few things to keep in mind:

  • While implementing parallel algorithms, it might be better to spawn as many threads as there are cores. (Runtime.getRuntime().availableProcessors()). Not more, not less.
  • Make use of the facilities provided by the java.util.concurrent package.
  • Make sure that you have Java Concurrency in Practice in your personal library.
dcsohl
  • 7,186
  • 1
  • 26
  • 44
Vijay Mathew
  • 26,737
  • 4
  • 62
  • 93
  • 3
    Not more, Not less. Incorrect. As per the book you suggested, one should spawn (No. of processors + 1), since while some thread is doing IO, the extra thread can make use of idle C.P.U. – garg10may May 30 '17 at 14:59
  • 5
    Threads are just doing some processing but not waiting for any remote calls(Like Database, Remote API, JMS and so on.. ) then the above suggestion makes sense. But in practical, all regular applications make use of Remote calls. So the best number of threads can be vary based on on latency of your remote calls. do load test and decide. – Venkateswara Rao May 01 '18 at 18:12
23

Green threads were replaced by native threads in Java 1.2.

Steve-o
  • 12,678
  • 2
  • 41
  • 60
  • 6
    +1 - In other words, the OS will arrange that different java threads using different cores ... depending on system scheduling and resource management constraints. – Stephen C Dec 14 '10 at 07:26