This question already has an answer here:

doing an lscpu cmd this is what i get

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Model name:            Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
Stepping:              0
CPU MHz:               2494.224
BogoMIPS:              4988.44
Hypervisor vendor:     VMware
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,1

doing the math tells me it should be able to run 2 threads at a given time

Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 2

however the tomcat configuration sets the max threads at 150

redirectPort="8443" maxThreads="150" acceptCount="15" enableLookups="true"

how does the web application support 150 max threads when the cpu only supports 2?

marked as duplicate by gnat, Robert Harvey, Arseni Mourzenko, Doc Brown, Thomas Owens Jan 17 '17 at 10:24

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • thanks. seems like the answer has to do with whether application is io bound vs cpu bound. this question can be closed. – rtd353 Jan 16 '17 at 21:04
  • "a single core is only capable of running a single thread at a given moment" is this statement true? – rtd353 Jan 16 '17 at 21:13
  • Note that the lscpu output doesn't entirely match the spec sheet for that processor – it should have 12 cores/24 threads. Perhaps it is confused by the presence of multiple CPU sockets, for my single-socket machine everything is displayed correctly. – amon Jan 16 '17 at 21:14
  • @amon And twice that if the "two sockets" is correct. – gnasher729 Jan 16 '17 at 21:37
  • @rtd353: A single core with hyperthreading (like this CPU) can "run" two threads at a time. However, that CPU has no problems having dozens of threads that can run one after the other. Right now the Mac on which I'm typing this (dual core, no hyper threading) has about 500 threads. – gnasher729 Jan 16 '17 at 21:42

There are two kinds of threads. Running threads and not-running threads, aka suspended threads.

Suspended (not-running) threads are merely data structures. Yes, these data structures necessarily have pointers to code, but they are still very much data structures in every sense of the word.

Suspended threads may be resumed and then later once again suspended. None the less, suspended threads are just state (data structures). Thus, ultimately, the computer is limited in suspended threads only by its capacity to store state, state being stored in memory, so which is to say suspended threads are limited only by memory capacity (modulo operating system design quirks/limitations).

Running threads, by contrast, require supporting hardware. We cannot have more running threads than we have hardware capabilities.

Still, under supervision of an operating system (thread scheduler), a running thread may be suspended and then a different suspended thread resumed, all of which makes it look like there are many more "running" threads than hardware has transistors for.


A web server like Tomcat is a great thing to thread because the vast majority of time the threads are not doing anything - they are, for example, blocked waiting for a request from the network. Yes, a single CPU core can only execute a single thread at any given instant. But it can also swap out that thread and switch to a new one very quickly.

Tomcat can spin up that many threads even on a single core CPU. The advantage is that, from a code architecture perspective, the code is much simpler to manage than having a single thread constantly check if there is any I/O to do or something like that.

A CPU bound process, where each thread uses a bunch of processing time is not suitable for this model. In this case, the CPU would thrash trying to process and switch contexts quickly and the code would likely run slower than if you ran task sequentially.

As the JVM interfaces with the O/S level, there can be different threading models too. The JDK used to have support for "green threads" (see some very old docs for more information). In the "green thread" model, multiple Java threads were mapped to a single native thread. But writing Java code with multiple threads still made sense for something like a web server because of task switching.

  • 1
    Hmm... Could have saved yourself a bit of time if you'd had a look at the comments below the question. – Robert Harvey Jan 16 '17 at 21:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.