Maximum Number of Threads Per Process in Linux

Maximum number of threads per process in Linux?

Linux doesn't have a separate threads per process limit, just a limit on the total number of processes on the system (threads are essentially just processes with a shared address space on Linux) which you can view like this:

cat /proc/sys/kernel/threads-max

The default is the number of memory pages/4. You can increase this like:

echo 100000 > /proc/sys/kernel/threads-max

There is also a limit on the number of processes (and hence threads) that a single user may create, see ulimit/getrlimit for details regarding these limits.

UNIX: Maximum number of threads in a program

set ulimit -s 4000 from terminal. Now you can run more thread than before, but you will meet segmentation fault in some stage.

number of threads = total virtual memory / (stack size*1024*1024)

The number of threads per process can be increased by increasing total
virtual memory or by decreasing stack size. But, decreasing stack size
too much can lead to code failure due to stack overflow while max
virtual memory is equals to the swap memory.

further information see this post clearly explained.

What is the maximum number of threads a process can have in windows

There is no limit that I know of, but there are two practical limits:

1. The virtual space for the stacks. For example in 32-bits the virtual space of the process is 4GB, but only about 2G are available for general use. By default each thread will reserve 1MB of stack space, so the top value are 2000 threads. Naturally you can change the size of the stack and make it lower so more threads will fit in (parameter dwStackSize in CreateThread or option /STACK in the linker command). If you use a 64-bits system this limit practically dissapears.
2. The scheduler overhead. Once you read the thousands of threads, just scheduling them will eat nearly 100% of your CPU time, so they are mostly useless anyway. This is not a hard limit, just your program will be slower and slower the more threads you create.

What is the maximum number of threads that can parallely execute a Java Object non-synchronized method?

There is always some maximum value, but what it is and how it is determined varies wildly. Among other things, the limit can be implicitly imposed by the total memory allocation pool limit on the JVM or by explicit OS-level restrictions. One way to get around the memory limit is to configure the JVM with lower stack size.

See this answer to find out how the limit is determined on Linux.

Why number of created thread is less than thread-max?

As mentioned by @1201ProgramAlarm and @Francois Andrieux in the comments. The thread-max value is a system wide limit and for creating much more threads we need to some modifications in kernel settings:

• Understanding the difference between pid_max, ulimit -u and thread_max
• Maximum number of threads per process in Linux?
  

Windows and linux max threads

For Windows, TechNet has an article by Mark Russinovich Pushing the Limits of Windows: Processes and Threads. The article also links to the testlimit tool, which lets you experiment on your system.

The TL;DR version is that it depends on Windows version, whether you're running 32- or 64-bit Windows, and whether your application is 32- or 64-bit, and for a 32-bit program whether you're linking your program as "large-address aware" (and the /3GB NTLDR option). It may also depend on ASLR. And it depends on whether you use the default thread stack reserve size, or adjust it.

A 32-bit non-large-adress-aware process running on a 32bit system without the /3GB switch, and the default 1meg stack reserve, will be limited to at most 2048 threads, but you'll very likely hit memory limits before that.

For a 64bit process with an adjusted stack size, you can probably expect hitting 40-50k threads with 2GB ram.

At any rate, if you're even close to hitting the 32-bit limits, you're Doing Things Wrong(TM). You don't want to be using blocking I/O with a thread per request - look into async I/O and thread pools (and all the fancy abstractions built on top of those).

---

Related Topics