java線程佔用內存

『壹』 java多線程開多少上限量。

Java線程默認的虛擬機內存分配為1M，但在4G的Windows系統中，線程數卻限制在300左右。這是因為Windows操作系統本身存在一定的限制。

虛擬機給每個線程分配的內存（棧空間）是通過-Xss參數指定的。根據Oracle官方文檔，不同平台上的默認值有所不同。例如，在64位Linux系統上，Xss的默認值為256K，而非1M或10M。

計算一個Java進程可以啟動的線程數，可以通過以下公式得出：（系統剩餘內存 - 最大堆容量Xmx - 最大方法區容量MaxPermSize）/ 最大棧空間Xss。因此，在4G的伺服器上，單個進程大致可以啟動5000個線程。

線程數的設置需要考慮系統的資源限制。如果線程數過多，可能會導致內存溢出，影響程序運行效率。相反，線程數過少則可能導致程序性能下降。因此，合理配置線程數對於提升程序性能至關重要。

在實際應用中，可以根據具體需求和系統配置調整線程數。例如，在處理大量並發請求時，可以適當增加線程數以提高處理效率。同時，還需要注意監控系統的資源使用情況，避免因線程數過多導致的問題。

正確配置線程數不僅可以提高程序性能，還可以確保系統的穩定運行。因此，在開發過程中，應充分考慮線程數的影響，並進行適當的調整。

了解線程數配置的原理有助於更好地優化程序性能。例如，可以通過監控工具實時查看系統資源使用情況，及時發現並解決問題。同時，還可以通過調整虛擬機參數來優化線程管理。

總之，合理配置線程數對於提升程序性能和系統穩定性至關重要。在實際應用中，應根據具體需求和系統配置進行調整，並定期檢查系統資源使用情況，確保程序穩定運行。

『貳』 新建一個JAVA線程，佔用的是JAVA堆內存還是操作系統的內存

Thread對象本身是在堆內存創建的，調用start()後開辟的線程空間是屬於棧內存的。內存管理在Java語言中是JVM自動操作的，當JVM發現某些對象不再需要的時候，就會對該對象佔用的內存進行重分配（釋放）操作，而且使得分配出來的內存能夠提供給所需要的對象。

在一些編程語言裡面，內存管理是一個程序的職責，但是書寫過C++的程序員很清楚，如果該程序需要自己來書寫很有可能引起很嚴重的錯誤或者說不可預料的程序行為，最終大部分開發時間都花在了調試這種程序以及修復相關錯誤上。

相關信息

在以前的編程過程中，手動內存管理帶了計算機程序不可避免的錯誤，而且這種錯誤對計算機程序是毀滅性的，所以內存管理就成為了一個很重要的話題，但是針對大多數純面向對象語言而言，比如Java，提供了語言本身具有的內存特性。

自動化內存管理，這種語言提供了一個程序垃圾回收器（Garbage Collector[GC]），自動內存管理提供了一個抽象的介面以及更加可靠的代碼使得內存能夠在程序裡面進行合理的分配。最常見的情況就是垃圾回收器避免了懸掛引用的問題。

因為一旦這些對象沒有被任何引用「可達」的時候，也就是這些對象在JVM的內存池裡面成為了不可引用對象，該垃圾回收器會直接回收掉這些對象佔用的內存，當然這些對象必須滿足垃圾回收器回收的某些對象規則，而垃圾回收器在回收的時候會自動釋放掉這些內存。

『叄』 Java應用程序中如何動態的分配CPU資源

方案選擇
在考慮動態分配CPU資源實施方案時，往往有以下兩點要求：

1. 須充分利用現有硬體資源，在系統空閑時，讓低優先順序任務也能夠得到系統所能給予最快響應。

2.當硬體資源超負荷運行時，雖然系統中有大規模、多數量任務不能處理，但它不應受影響，而能夠順利處理那些能夠被處理、最重要高優先順序任務。

多任務系統要用多線程實現最簡單方法就是將線程和任務一一對應，動態調整線程優先順序，利用線程調度來完成CPU資源在不同任務間動態分配。這種思路在以前使用本地化代碼(Native Code)，充分利用特定硬體和操作系統技巧基礎上是基本可行。但在跨平台Java環境中，這個思路對僅有小規模任務數簡單系統才可行，原因有以下兩點：

1. Java線程雖然在編程角度(API)是與平台無關，但它運行效果卻和不同操作系統平台密切相關。為了利用更多CPU資源，Java中一個線程(Thread)就對應著不同操作系統下一個真實線程。因為Java虛擬機沒有實現線程調度，所以這些Java線程在不同操作系統調度下運行差異性也就比較明顯。例如在Windows系統中，不僅線程優先順序少於Java API參數規定十個優先順序，而且微軟明確反對程序員動態調整線程優先順序。即使在操作系統中有足夠優先權，讓線程優先順序參數和真實線程優先順序對應，不同操作系統調度方式也會有許多不同。這最終會造成代碼在不同平台上行為變得不可預測。這就很難滿足復雜、大規模並發任務眾多優先順序需求，從而很難達到用戶業務需要達到效果。

2. 由於在Java系統中，線程被包裝在一個Java語言對象類—Thread中，所以為了完成Java語言對象和操作系統線程對應，Java線程系統開銷還是比較大(在NT 4.0中，平均每個線程大致佔用30KB內存)。因此如果讓Thread對象個數和成千上萬任務數同比例增長，就顯然是不合理。

內容摘要：本文利用協調式多任務模型，提出一個與平台無關、並且能在任務間動態分配CPU資源方案。
綜上所述，根據並發多任務大規模需求和Java平台固有特點，想要利用Java Thread對象優先順序調整CPU資源分配是非常困難，所以應該盡量避免讓線程和任務直接對應，也盡量避免使用操作系統線程優先順序調度機制。

解決方案

根據以上分析，問題症結在於：多任務系統中任務在Java語言中對應以及任務間相互調度。

從本質上看，一個任務就是一系列對象方法調用序列，與JavaThread對象或者別類對象沒有必然聯系。在避免使用不同操作系統線程調度且同時Java虛擬機又沒有線程調度能力情況下，要想構造一個協調式多任務系統，讓各個任務相互配合就成了最直接思路。協調式多任務系統一般有以下特點：

1. 任務由消息驅動，消息響應代碼完成任務邏輯處理;

2. 消息隊列完成消息存儲和管理，從而利用消息處理次序體現任務優先順序不同;

3. 任務中耗時消息響應邏輯能夠主動放棄CPU資源，讓別任務執行(像Windows 3.1中Yield函數、Visual Basic中DoEvents語句)。

可能出於巧合，Java語言具有構造協調式多任務系統天然條件。Java對象方法不僅是一個函數調用，它還是一個java.lang.reflect.Method類對象。而所有對象方法都可以通過Method類invoke方法調用。如果能使每個任務所對應一系列方法全部以對象形式包裝成消息，放到消息隊列中，然後再按照自己優先順序演算法將隊列中消息取出，執行其Method對象invoke調用，那麼一個基本協調式多任務系統就形成了。其中，任務優先順序和線程優先順序沒有綁定關系。該系統主體調度函數可以設置成一個「死循環」，按照需要優先順序演算法處理消息隊列。對於有多重循環、外設等待等耗時操作消息響應函數，可以在響應函數內部遞歸調用主體調度函數,這一次調用把原來「死循環」改成在消息隊列長度減少到一定程度(或者為空)後退出。退出後，函數返回，執行剛才沒有完成消息響應邏輯，這樣就非常自然地實現了協調式系統中任務主動放棄CPU資源要求。

『肆』 java多線程開多少上限量。

1。java的線程開啟，默認的虛擬機會分配1M的內存，但是在4G的windows上線程最多也就開到300多 ，是因為windows本身的一些限制導致。

2。虛擬機給每個線程分配的內存（棧空間）是由虛擬機參數-Xss來指定的，在不同平台上對應的默認大小可以 在oracle的官方文檔上查詢到：
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman /optionX.html
其中，Linux64位默認Xss值為256K，並非1M或10M

3。一個Java進程可以啟動的線程數可以通過如下公式計算：

（系統剩餘內存 - 最大堆容量Xmx - 最大方法區容量MaxPermSize）／ 最大棧空間Xss

這樣，4G的伺服器單個進程可以開多少線程，可以粗略計算出來，大概是5000個線程。