Java虛擬機最多支撐若干個線程的商量。本站提示廣大學習愛好者：（Java虛擬機最多支撐若干個線程的商量）文章只能為提供參考，不一定能成為您想要的結果。以下是Java虛擬機最多支撐若干個線程的商量正文
McGovernTheory在StackOverflow提了如許一個成績:
Java虛擬機最多支撐若干個線程？跟虛擬機開辟商有關麼？跟操作體系呢？還有其他的身分嗎？
Eddie的答復:
這取決於你應用的CPU，操作體系，其他過程正在做的工作，你應用的Java的版本，還有其他的身分。我已經見過一台Windows辦事器在宕機之前有跨越6500個線程。固然，年夜多半線程甚麼工作也沒有做。一旦一台機械上有差不多6500個線程（Java外面），機械就會開端出成績，並變得不穩固。
以我的經歷來看，JVM包容的線程與盤算機自己機能是正相干的。
固然了，你要有足夠的本機內存，而且給Java分派了足夠的內存，讓每一個線程都可以具有棧(虛擬機棧)，可以做任何想做的工作。任何一台具有古代CPU（AMD或許是Intel比來的幾代）和1-2G內存（取決於操作體系）的機械很輕易便可以支撐有上千個線程的Java虛擬機。
假如你須要一個更准確的謎底，最好是本身做壓測。
Charlie Martin的答復:
這裡有許多的參數（可以設置）。關於特定的虛擬機，都邑有本身的運轉時參數。（最年夜線程數）必定水平上由操作體系決議的：底層的操作體系要給線程供給哪些支撐？施加哪些限制？虛擬機應用的是原生的操作體系的線程照樣red thread或許green thread？
操作體系供給的支撐是另外一個成績。假如你向上面如許寫Java法式：
class DieLikeADog {
public static void main(String[] argv){
for(;;){
new Thread(new SomeRunaable).start();
}
}
}
(不要埋怨語法細節，這才方才開端)那你固然願望能獲得成百上千個運轉的線程。然則，創立一個線程的本錢是絕對較年夜的，(過量線程)調劑的開支會變得凸起。可否讓這些線程做有效的工作還不肯定。
進級版
好了，迫在眉睫了！上面是我的一個加了點潤飾的小的測試法式：
public class DieLikeADog {
private static Object s = new Object();
private static int count = 0;
public static void main(String[] argv){
for(;;){
new Thread(new Runnable(){
public void run(){
synchronized(s){
count += 1;
System.err.println("New thread #"+count);
}
for(;;){
try {
Thread.sleep(1000);
} catch (Exception e){
System.err.println(e);
}
}
}
}).start();
}
}
}
在Intel的OS/X 10.5.6體系上，Java 5的輸入以下：
New thread #2547
New thread #2548
New thread #2549
Can't create thread: 5
New thread #2550
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:592)
at DieLikeADog.main(DieLikeADog.java:6)
benjismith的答復:
讀了Charlie Martin的答復今後，我很想曉得堆內存的年夜小能否可以或許給創立的線程數帶來分歧，然後我就被成果驚呆了：在Vista Home Premium SP1體系上，應用JDK 1.6.0_11，設置堆內存的年夜小從2M到1024M來履行Charlie的測試法式。好比：創立2M的堆內存，我應用的虛擬機參數是：-Xms2m -Xmx2m.
上面是我的測試成果：
2 mb --> 5744 threads
4 mb --> 5743 threads
8 mb --> 5735 threads
12 mb --> 5724 threads
16 mb --> 5712 threads
24 mb --> 5687 threads
32 mb --> 5662 threads
48 mb --> 5610 threads
64 mb --> 5561 threads
96 mb --> 5457 threads
128 mb --> 5357 threads
192 mb --> 5190 threads
256 mb --> 5014 threads
384 mb --> 4606 threads
512 mb --> 4202 threads
768 mb --> 3388 threads
1024 mb --> 2583 threads
所以，堆的年夜小確切很主要。然則，堆年夜小和最年夜線程數倒是呈正比例關系。
這太詭異了！
Neil Coffey的答復:
相對實際上的最年夜線程數是過程的用戶地址空間除以線程棧的年夜小（實際中，假如內存全體給線程棧應用，就不會有能運轉的法式了）。是以，以32位Windows體系為例，每個過程的用戶地址空間是2G，假設每一個線程棧的年夜小是128K，最多會有16384(=2*1024*1024 / 128)個線程。現實在XP體系上，我發明年夜約能啟動13000個線程。
然後，我以為，你的成績實質上是：(a)你能否可以在你的代碼中有用的治理很多的線程，不讓他們做很明顯是愚昧的工作（好比：讓他們在統一個object對象上期待隨後被挪用notifyAll()…）,（b）操作體系能否可以有用地治理這很多線程。根本下去說，假如(a)的謎底是”yes”的話，(b)的謎底也是”yes”。
很巧的是，你可以在Thread的結構函數中設置線程棧的年夜小，然則，你不須要也不該該把這個和虛擬機參數弄混雜。
