❶ 查看linux系統中各文件系統磁碟空間佔用
linux中df命令的功能是用來檢查linux伺服器的文件系統的磁碟空間佔用情況。可以利用該命令來獲取硬碟被佔用了多少空間，目前還剩下多少空間等信息。
1．命令格式：
df [選項] [文件]
2．命令功能：
顯示指定磁碟文件的可用空間。如果沒有文件名被指定，則所有當前被掛載的文件系統的可用空間將被顯示。默認情況下，磁碟空間將以 1KB 為單位進行顯示，除非環境變數 POSIXLY_CORRECT 被指定，那樣將以512位元組為單位進行顯示
3．命令參數：
必要參數：
-a 全部文件系統列表
-h 方便閱讀方式顯示
-H 等於「-h」，但是計算式，1K=1000，而不是1K=1024
-i 顯示inode信息
-k 區塊為1024位元組
-l 只顯示本地文件系統
-m 區塊為1048576位元組
--no-sync 忽略 sync 命令
-P 輸出格式為POSIX
--sync 在取得磁碟信息前，先執行sync命令
-T 文件系統類型
選擇參數：
--block-size=<區塊大小> 指定區塊大小
-t<文件系統類型> 只顯示選定文件系統的磁碟信息
-x<文件系統類型> 不顯示選定文件系統的磁碟信息
--help 顯示幫助信息
--version 顯示版本信息
4．使用實例：
實例1：顯示磁碟使用情況
命令：
df
輸出：
[root@CT1190 log]# df
文件系統 1K-塊 已用 可用 已用% 掛載點
/dev/sda7 19840892 890896 17925856 5% /
/dev/sda9 203727156 112797500 80413912 59% /opt
/dev/sda8 4956284 570080 4130372 13% /var
/dev/sda6 19840892 1977568 16839184 11% /usr
/dev/sda3 988116 23880 913232 3% /boot
tmpfs 16473212 0 16473212 0% /dev/shm
說明：
linux中df命令的輸出清單的第1列是代表文件系統對應的設備文件的路徑名（一般是硬碟上的分區）；第2列給出分區包含的數據塊（1024位元組）的數目；第3，4列分別表示已用的和可用的數據塊數目。用戶也許會感到奇怪的是，第3，4列塊數之和不等於第2列中的塊數。這是因為預設的每個分區都留了少量空間供系統管理員使用。即使遇到普通用戶空間已滿的情況，管理員仍能登錄和留有解決問題所需的工作空間。清單中Use% 列表示普通用戶空間使用的百分比，即使這一數字達到100％，分區仍然留有系統管理員使用的空間。最後，Mounted on列表示文件系統的掛載點。
實例2：以inode模式來顯示磁碟使用情況
命令：
df -i
輸出：
[root@CT1190 log]# df -i
文件系統 Inode (I)已用 (I)可用 (I)已用% 掛載點
/dev/sda7 5124480 5560 5118920 1% /
/dev/sda9 52592640 50519 52542121 1% /opt
/dev/sda8 1280000 8799 1271201 1% /var
/dev/sda6 5124480 80163 5044317 2% /usr
/dev/sda3 255232 34 255198 1% /boot
tmpfs 4118303 1 4118302 1% /dev/shm
說明：
實例3：顯示指定類型磁碟
命令：
df -t ext3
輸出：
[root@CT1190 log]# df -t ext3
文件系統 1K-塊 已用 可用 已用% 掛載點
/dev/sda7 19840892 890896 17925856 5% /
/dev/sda9 203727156 93089700 100121712 49% /opt
/dev/sda8 4956284 570104 4130348 13% /var
/dev/sda6 19840892 1977568 16839184 11% /usr
/dev/sda3 988116 23880 913232 3% /boot
說明：
實例4：列出各文件系統的i節點使用情況
命令：
df -ia
輸出：
[root@CT1190 log]# df -ia
文件系統 Inode (I)已用 (I)可用 (I)已用% 掛載點
/dev/sda7 5124480 5560 5118920 1%
/proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
devpts 0 0 0 - /dev/pts
/dev/sda9 52592640 50519 52542121 1% /opt
/dev/sda8 1280000 8799 1271201 1% /var
/dev/sda6 5124480 80163 5044317 2% /usr
/dev/sda3 255232 34 255198 1% /boot
tmpfs 4118303 1 4118302 1% /dev/shm
none 0 0 0 - /proc/sys/fs/binfmt_misc
說明：
實例5：列出文件系統的類型
命令：
df -T
輸出：
root@CT1190 log]# df -T
文件系統 類型 1K-塊 已用 可用 已用% 掛載點
/dev/sda7 ext3 19840892 890896 17925856 5% /
/dev/sda9 ext3 203727156 93175692 100035720 49% /opt
/dev/sda8 ext3 4956284 570104 4130348 13% /var
/dev/sda6 ext3 19840892 1977568 16839184 11% /usr
/dev/sda3 ext3 988116 23880 913232 3% /boot
tmpfs tmpfs 16473212 0 16473212 0% /dev/shm
說明：
實例6：以更易讀的方式顯示目前磁碟空間和使用情況
命令：
輸出：
[root@CT1190 log]# df -h
文件系統 容量 已用 可用 已用% 掛載點
/dev/sda7 19G 871M 18G 5% /
/dev/sda9 195G 89G 96G 49% /opt
/dev/sda8 4.8G 557M 4.0G 13% /var
/dev/sda6 19G 1.9G 17G 11% /usr
/dev/sda3 965M 24M 892M 3% /boot
tmpfs 16G 0 16G 0% /dev/shm
[root@CT1190 log]# df -H
文件系統 容量 已用 可用 已用% 掛載點
/dev/sda7 21G 913M 19G 5% /
/dev/sda9 209G 96G 103G 49% /opt
/dev/sda8 5.1G 584M 4.3G 13% /var
/dev/sda6 21G 2.1G 18G 11% /usr
/dev/sda3 1.1G 25M 936M 3% /boot
tmpfs 17G 0 17G 0% /dev/shm
[root@CT1190 log]# df -lh
文件系統 容量 已用 可用 已用% 掛載點
/dev/sda7 19G 871M 18G 5% /
/dev/sda9 195G 89G 96G 49% /opt
/dev/sda8 4.8G 557M 4.0G 13% /var
/dev/sda6 19G 1.9G 17G 11% /usr
/dev/sda3 965M 24M 892M 3% /boot
tmpfs 16G 0 16G 0% /dev/shm
[root@CT1190 log]# df -k
文件系統 1K-塊 已用 可用 已用% 掛載點
/dev/sda7 19840892 890896 17925856 5% /
/dev/sda9 203727156 93292572 99918840 49% /opt
/dev/sda8 4956284 570188 4130264 13% /var
/dev/sda6 19840892 1977568 16839184 11% /usr
/dev/sda3 988116 23880 913232 3% /boot
tmpfs 16473212 0 16473212 0% /dev/shm
說明：
-h更具目前磁碟空間和使用情況 以更易讀的方式顯示
-H根上面的-h參數相同,不過在根式化的時候,採用1000而不是1024進行容量轉換
-k以單位顯示磁碟的使用情況
-l顯示本地的分區的磁碟空間使用率,如果伺服器nfs了遠程伺服器的磁碟,那麼在df上加上-l後系統顯示的是過濾nsf驅動器後的結果
-i顯示inode的使用情況。linux採用了類似指針的方式管理磁碟空間影射.這也是一個比較關鍵應用
❷ 如何動態察看多線程程序堆棧使用情況
1) 線程堆棧概述及基礎知識
2) 線程堆棧的生成原理以及相關工具
3) 不同JVM線程堆棧的格式的差異（Sun HotSpot、IBM JRE、Oracal JRockit）
4) 線程堆棧日誌介紹以及解析方法
5) 線程堆棧的分析和相關的技術
6) 常見的問題模板（線程竟態、死鎖、IO調用掛死、垃圾回收/OutOfMemoryError問題、死循環等）
7) 線程堆棧問題實例分析
我希望這一系列的培訓能給你帶來確實的幫助，所以請持續關注每周的文章更新。
但是如果我在學習過程中有疑問或者無法理解文章中的內容該怎麼辦？
不用擔心，把我當做你的導師就好。任何關於線程堆棧的問題都可以咨詢我（前提是問題不能太low）。請隨意選擇下面的幾種方式與我取得聯系：
1) 直接本文下面發表評論（不好意思的話可以匿名）
2) 將你的線程堆棧數據提交到Root Cause Analysis forum
3) 發Email給我，地址是 @[email protected]
能幫我分析我們產品上遇到的問題么？
當然可以，如果你願意的話可以把你的堆棧現場數據通過郵件或論壇 Root Cause Analysis forum發給我。處理實際問題是才是學習提升技能的王道。
我真心期望大家能夠喜歡這個培訓。所以我會盡我所能去為你提供高質量的材料，並回答大家的各種問題。
在介紹線程堆棧分析技術和問題模式之前，先要給大家講講基礎的內容。所以在這篇帖子里，我將先覆蓋到最基本的內容，這樣大家就能更好的去理解JVM、中間件、以及Java EE容器之間的交互。
Java VM 概述
Java虛擬機是Jave EE 平台的基礎。它是中間件和應用程序被部署和運行的地方。
JVM向中間件軟體和你的Java/Java EE程序提供了下面這些東西:
– （二進制形式的）Java / Java EE 程序運行環境
– 一些程序功能特性和工具 (IO 基礎設施，數據結構，線程管理，安全，監控 等等.)
– 藉助垃圾回收的動態內存分配與管理
你的JVM可以駐留在許多的操作系統 (Solaris, AIX, Windows 等等.)之上，並且能根據你的物理伺服器配置，你可以在每台物理/虛擬伺服器上安裝1到多個JVM進程.
JVM與中間件之間的交互
下面這張圖展示了JVM、中間件和應用程序之間的高層交互模型。
圖中展示的JVM、中間件和應用程序件之間的一些簡單和典型的交互。如你所見，標准Java EE應用程序的線程的分配實在中間件內核與JVM之間完成的。（當然也有例外，應用程序可以直接調用API來創建線程，這種做法並不常見，而且在使用的過程中也要特別的小心）
同時，請注意一些線程是由JVM內部來進行管理的，典型的例子就是垃圾回收線程，JVM內部使用這個線程來做並行的垃圾回收處理。
因為大多數的線程分配都是由Java EE容器完成的，所以能夠理解和認識線程堆棧跟蹤，並能從線程堆棧數據中識別出它來，對你而言很重要. 這可以讓你能夠快速的知道Java EE容器正要執行的是什麼類型的請求.
從一個線程轉儲堆棧的分析角度來看，你將能了解從JVM發現的線程池之間的不同，並識別出請求的類型.
最後一節會向你提供對於HotSop VM而言什麼是JVM線程堆棧的一個概述，還有你將會遇到的各種不同的線程. 而對 IBM VM 線程堆棧形式詳細內容將會在第四節向你提供.
請注意你可以從根本原因分析論壇獲得針對本文的線程堆棧示例.
JVM 線程堆棧——它是什麼?
JVM線程堆棧是一個給定時間的快照，它能向你提供所有被創建出來的Java線程的完整清單.
每一個被發現的Java線程都會給你如下信息:
– 線程的名稱；經常被中間件廠商用來識別線程的標識，一般還會帶上被分配的線程池名稱以及狀態 (運行，阻塞等等.)
– 線程類型 & 優先順序，例如 : daemon prio=3 ** 中間件程序一般以後台守護的形式創建他們的線程，這意味著這些線程是在後台運行的；它們會向它們的用戶提供服務，例如：向你的Java EE應用程序 **
– Java線程ID，例如 : tid=0x000000011e52a800 ** 這是通過 java.lang.Thread.getId() 獲得的Java線程ID，它常常用自增長的長整形 1..n** 實現
– 原生線程ID，例如 : nid=0x251c** ，之所以關鍵是因為原生線程ID可以讓你獲得諸如從操作系統的角度來看那個線程在你的JVM中使用了大部分的CPU時間等這樣的相關信息. **
– Java線程狀態和詳細信息，例如: waiting for monitor entry [0xfffffffea5afb000] java.lang.Thread.State: BLOCKED (on object monitor)
** 可以快速的了解到線程狀態極其當前阻塞的可能原因 **
– Java線程棧跟蹤；這是目前為止你能從線程堆棧中找到的最重要的數據. 這也是你花費最多分析時間的地方，因為Java棧跟蹤向提供了你將會在稍後的練習環節了解到的導致諸多類型的問題的根本原因，所需要的90%的信息。
– Java 堆內存分解; 從HotSpot VM 1.6版本開始，在線程堆棧的末尾處可以看到HotSpot的內存使用情況，比如說Java的堆內存(YoungGen, OldGen) & PermGen 空間。這個信息對分析由於頻繁GC而引起的問題時，是很有用的。你可以使用已知的線程數據或模式做一個快速的定位。
Heap PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000) eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000) from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000) to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000) PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000) object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000) PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000) object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)
線程堆棧信息大拆解
為了讓大家更好的理解，給大家提供了下面的這張圖，在這張圖中將HotSpot VM上的線程堆棧信息和線程池做了詳細的拆解，如下圖所示：
上圖中可以看出線程堆棧是由多個不同部分組成的。這些信息對問題分析都很重要，但對不同的問題模式的分析會使用不同的部分（問題模式會在後面的文章中做模擬和演示。）
現在通過這個分析樣例，給大家詳細解釋一下HoteSpot上線程堆棧信息中的各個組成部分：
# Full thread mp標示符
「Full thread mp」是一個全局唯一的關鍵字，你可以在中間件和單機版本Java的線程堆棧信息的輸出日誌中找到它（比如說在UNIX下使用：kill -3 <PID> ）。這是線程堆棧快照的開始部分。
Full thread mp Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
# Java EE 中間件,第三方以及自定義應用軟體中的線程
這個部分是整個線程堆棧的核心部分，也是通常需要花費最多分析時間的部分。堆棧中線程的個數取決你使用的中間件，第三方庫（可能會有獨立線程）以及你的應用程序（如果創建自定義線程，這通常不是一個很好的實踐）。
在我們的示例線程堆棧中，WebLogic是我們所使用的中間件。從Weblogic 9.2開始, 會使用一個用「』weblogic.kernel.Default (self-tuning)」唯一標識的能自行管理的線程池
"[STANDBY] ExecuteThread: '414' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x000000010916a800 nid=0x2613 in Object.wait() [0xfffffffe9edff000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xffffffff27d44de0> (a weblogic.work.ExecuteThread) at java.lang.Object.wait(Object.java:485) at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:160) - locked <0xffffffff27d44de0> (a weblogic.work.ExecuteThread) at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
# HotSpot VM 線程
這是一個有Hotspot VM管理的內部線程，用於執行內部的原生操作。一般你不用對此操太多心，除非你(通過相關的線程堆棧以及 prstat或者原生線程Id)發現很高的CPU佔用率.
"VM Periodic Task Thread" prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition
❸ 如何查看當前linux系統給JVM分配了多大的內存
以WAS為例：
[tmp]$ ps -ef | grep java
root 9787 1 0 Sep17 ? 00:02:48 /opt/IBM/WebSphere/AppServer/java/bin/java -Xms50m -Xmx256m
-Xms 和 -Xmx 分別代表分配JVM的最小內存和最大內存。
堆棧信息你可以用 kill -3 後面跟上java進程的pid，這樣就能生成 thread mp 了。
具體如下：
1、簡介C語言是一門通用計算機編程語言，應用廣泛。C語言的設計目標是提供一種能以簡易的方式編譯、處理低級存儲器、產生少量的機器碼以及不需要任何運行環境支持便能運行的編程語言。盡管C語言提供了許多低級處理的功能，但仍然保持著良好跨平台的特性，以一個標准規格寫出的C語言程序可在許多電腦平台上進行編譯，甚至包含一些嵌入式處理器（單片機或稱MCU）以及超級電腦等作業平台。
2、基本介紹
C語言，是一種通用的、過程式的編程語言，廣泛用於系統與應用軟體的開發。具有高效、靈活、功能豐富、表達力強和較高的移植性等特點，在程序員中備受青睞。最近25年是使用最為廣泛的編程語言。
3、運算
C語言的運算非常靈活，功能十分豐富，運算種類遠多於其它程序設計語言。在表達式方面較其它程序語言更為簡潔，如自加、自減、逗號運算和三目運算使表達式更為簡單，但初學者往往會覺的這種表達式難讀，關鍵原因就是對運算符和運算順序理解不透不全。當多種不同運算組成一個運算表達式，即一個運算式中出現多種運算符時，運算的優先順序和結合規則顯得十分重要。在學習中，對此合理進行分類，找出它們與數學中所學到運算之間的不同點之後，記住這些運算也就不困難了，有些運算符在理解後更會牢記心中，將來用起來得心應手，而有些可暫時放棄不記，等用到時再記不遲。
❹ 請問 怎樣分別查看windows系統與Linux系統的棧空間大小
linux和windows下同樣的文件或文件夾的大小有什麼區別1.window下文件夾不算大小，linux下文件夾要算大小2.兩個系統下的文件系統可能不一樣，不同的文件系統，blocksize可能不一樣。blocksize不一樣，文件佔用的磁碟空間可能就不一樣。不同操作系統下查看blocksize的命令： AIX：lsfs -q /u01 Windows：fsutil fsinfo ntfsinfo c:linux：tune2fs -l /dev/sda1 3.window和linux下，文本文件的換行符不同，windows下是/n/r，linux下是/n。當使用FTP傳輸文本文件時，默認會進行換行符的轉換，造成傳輸前後文件大小不一致。4.要確認看到的文件大小是指文件本身的大小，還是文件佔用的磁碟空間的大小，兩者概念不同。
❺ 如何判斷是否是棧空間不夠》
1）程序中有兩個這樣的char數組，算下來，一個char是一個位元組，兩個2048*2048的數組便是8MB的空間。
2）而使用ulimit -a查看Linux系統中設置的棧空間大小stack size，8192(單位KB)，即8MB，，也可用ulimit -s可以只看棧空間大小。可見棧空間已經不夠用了，在調用該函數的時候，在棧空間中為該函數開辟空間，因為已經開辟不出這么大的空間了，於是段錯誤了，程序目前尚未進入該函數，因為在裝載該函數的時候掛掉了。所以即使給該函數第一行加輸出信息，也輸出不了。
3）使用ulimit -s 10240修改棧大小為10M，重新運行程序，程序正常運行無段錯誤
4）由此可證，的確是系統棧空間大小太小導致程序段錯誤，當然如果改成new malloc等方式在堆區申請空間則不會段錯誤。
❻ 如何查看當前Linux系統的狀態,如CPU使用,內存使用,負載情況等.
可以用TOP工具查看實時狀態。
top進入視圖：
第一行：
10:01:23 當前系統時間
126 days, 14:29 系統已經運行了126天14小時29分鍾（在這期間沒有重啟過）
2 users 當前有2個用戶登錄系統
load average: 1.15, 1.42, 1.44 load average後面的三個數分別是1分鍾、5分鍾、15分鍾的負載情況。
load average數據是每隔5秒鍾檢查一次活躍的進程數，然後按特定演算法計算出的數值。如果這個數除以邏輯CPU的數量，結果高於5的時候就表明系統在超負荷運轉了。
第二行：
Tasks 任務（進程），系統現在共有183個進程，其中處於運行中的有1個，182個在休眠（sleep），stoped狀態的有0個，zombie狀態（僵屍）的有0個。
第三行：cpu狀態
6.7% us 用戶空間佔用CPU的百分比。
0.4% sy 內核空間佔用CPU的百分比。
0.0% ni 改變過優先順序的進程佔用CPU的百分比
92.9% id 空閑CPU百分比
0.0% wa IO等待佔用CPU的百分比
0.0% hi 硬中斷（Hardware IRQ）佔用CPU的百分比
0.0% si 軟中斷（Software Interrupts）佔用CPU的百分比
第四行：內存狀態
8306544k total 物理內存總量（8GB）
7775876k used 使用中的內存總量（7.7GB）
530668k free 空閑內存總量（530M）
79236k buffers 緩存的內存量 （79M）
第五行：swap交換分區
2031608k total 交換區總量（2GB）
2556k used 使用的交換區總量（2.5M）
2029052k free 空閑交換區總量（2GB）
4231276k cached 緩沖的交換區總量（4GB）
❼ Linux下怎麼查看內存使用情況和CPU利用率
1. 在系統維護的過程中，隨時可能有需要查看 CPU 使用率，並根據相應信息分析系統狀況的需要。在 CentOS 中，可以通過 top 命令來查看 CPU 使用狀況。運行 top 命令後，CPU 使用狀態會以全屏的方式顯示，並且會處在對話的模式 -- 用基於 top 的命令，可以控制顯示方式等等。退出 top 的命令為 q （在 top 運行中敲 q 鍵一次）。
top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源佔用狀況，類似於Windows的任務管理器
可以直接使用top命令後，查看%MEM的內容。可以選擇按進程查看或者按用戶查看，如想查看oracle用戶的進程內存使用情況的話可以使用如下的命令：
$ top -u oracle
2. 釋義：
PID：進程的ID
USER：進程所有者
PR：進程的優先順序別，越小越優先被執行
NInice：值
VIRT：進程佔用的虛擬內存
RES：進程佔用的物理內存
SHR：進程使用的共享內存
S：進程的狀態。S表示休眠，R表示正在運行，Z表示僵死狀態，N表示該進程優先值為負數
%CPU：進程佔用CPU的使用率
%MEM：進程使用的物理內存和總內存的百分比
TIME+：該進程啟動後佔用的總的CPU時間，即佔用CPU使用時間的累加值。
COMMAND：進程啟動命令名稱
3.操作實例:
在命令行中輸入 「top」
即可啟動 top
top 的全屏對話模式可分為3部分：系統信息欄、命令輸入欄、進程列表欄。
第一部分 -- 最上部的 系統信息欄 ：
第一行（top）：
「00:11:04」為系統當前時刻；
「3:35」為系統啟動後到現在的運作時間；
「2 users」為當前登錄到系統的用戶，更確切的說是登錄到用戶的終端數 -- 同一個用戶同一時間對系統多個終端的連接將被視為多個用戶連接到系統，這里的用戶數也將表現為終端的數目；
「load average」為當前系統負載的平均值，後面的三個值分別為1分鍾前、5分鍾前、15分鍾前進程的平均數，一般的可以認為這個數值超過 CPU 數目時，CPU 將比較吃力的負載當前系統所包含的進程；
第二行（Tasks）：
「59 total」為當前系統進程總數；
「1 running」為當前運行中的進程數；
「58 sleeping」為當前處於等待狀態中的進程數；
「0 stoped」為被停止的系統進程數；
「0 zombie」為被復原的進程數；
第三行（Cpus）：
分別表示了 CPU 當前的使用率；
第四行（Mem）：
分別表示了內存總量、當前使用量、空閑內存量、以及緩沖使用中的內存量；
第五行（Swap）：
表示類別同第四行（Mem），但此處反映著交換分區（Swap）的使用情況。通常，交換分區（Swap）被頻繁使用的情況，將被視作物理內存不足而造成的。
第二部分 -- 中間部分的內部命令提示欄：
top 運行中可以通過 top 的內部命令對進程的顯示方式進行控制。內部命令如下表：
s
- 改變畫面更新頻率
l - 關閉或開啟第一部分第一行 top 信息的表示
t - 關閉或開啟第一部分第二行 Tasks 和第三行 Cpus 信息的表示
m - 關閉或開啟第一部分第四行 Mem 和 第五行 Swap 信息的表示
N - 以 PID 的大小的順序排列表示進程列表（第三部分後述）
P - 以 CPU 佔用率大小的順序排列進程列表 （第三部分後述）
M - 以內存佔用率大小的順序排列進程列表 （第三部分後述）
h - 顯示幫助
n - 設置在進程列表所顯示進程的數量
q - 退出 top
s -
改變畫面更新周期
第三部分 -- 最下部分的進程列表欄：
以 PID 區分的進程列表將根據所設定的畫面更新時間定期的更新。通過 top 內部命令可以控制此處的顯示方式
pmap
可以根據進程查看進程相關信息佔用的內存情況，(進程號可以通過ps查看)如下所示：
$ pmap -d 5647
ps
如下例所示：
$ ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' 其中rsz是是實際內存
$ ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep oracle | sort -nrk
其中rsz為實際內存，上例實現按內存排序，由大到小
在Linux下查看內存我們一般用free命令：
[root@scs-2 tmp]# free
total used free shared buffers cached
Mem: 3266180 3250004 16176 0 110652 2668236
-/+ buffers/cache: 471116 2795064
Swap: 2048276 80160 1968116
下面是對這些數值的解釋：
total:總計物理內存的大小。
used:已使用多大。
free:可用有多少。
Shared:多個進程共享的內存總額。
Buffers/cached:磁碟緩存的大小。
第三行(-/+ buffers/cached):
used:已使用多大。
free:可用有多少。
第四行就不多解釋了。
區別：第二行(mem)的used/free與第三行(-/+ buffers/cache) used/free的區別。 這兩個的區別在於使用的角度來看，第一行是從OS的角度來看，因為對於OS，buffers/cached 都是屬於被使用，所以他的可用內存是16176KB,已用內存是3250004KB,其中包括，內核（OS）使用+Application(X, oracle,etc)使用的+buffers+cached.
第三行所指的是從應用程序角度來看，對於應用程序來說，buffers/cached 是等於可用的，因為buffer/cached是為了提高文件讀取的性能，當應用程序需在用到內存的時候，buffer/cached會很快地被回收。
所以從應用程序的角度來說，可用內存=系統free memory+buffers+cached。
如上例：
2795064=16176+110652+2668236
接下來解釋什麼時候內存會被交換，以及按什麼方交換。 當可用內存少於額定值的時候，就會開會進行交換。
如何看額定值：
cat /proc/meminfo
[root@scs-2 tmp]# cat /proc/meminfo
MemTotal: 3266180 kB
MemFree: 17456 kB
Buffers: 111328 kB
Cached: 2664024 kB
SwapCached: 0 kB
Active: 467236 kB
Inactive: 2644928 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 3266180 kB
LowFree: 17456 kB
SwapTotal: 2048276 kB
SwapFree: 1968116 kB
Dirty: 8 kB
Writeback: 0 kB
Mapped: 345360 kB
Slab: 112344 kB
Committed_AS: 535292 kB
PageTables: 2340 kB
VmallocTotal: 536870911 kB
VmallocUsed: 272696 kB
VmallocChunk: 536598175 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB
用free -m查看的結果：
[root@scs-2 tmp]# free -m
total used free shared buffers cached
Mem: 3189 3173 16 0 107 2605
-/+ buffers/cache: 460 2729
Swap: 2000 78 1921
查看/proc/kcore文件的大小（內存鏡像）：
[root@scs-2 tmp]# ll -h /proc/kcore
-r-------- 1 root root 4.1G Jun 12 12:04 /proc/kcore
備註：
佔用內存的測量
測量一個進程佔用了多少內存，linux為我們提供了一個很方便的方法，/proc目錄為我們提供了所有的信息，實際上top等工具也通過這里來獲取相應的信息。
/proc/meminfo 機器的內存使用信息
/proc/pid/maps pid為進程號，顯示當前進程所佔用的虛擬地址。
/proc/pid/statm 進程所佔用的內存
[root@localhost ~]# cat /proc/self/statm
654 57 44 0 0 334 0
輸出解釋
CPU 以及CPU0。。。的每行的每個參數意思（以第一行為例）為：
參數 解釋 /proc//status
Size (pages) 任務虛擬地址空間的大小 VmSize/4
Resident(pages) 應用程序正在使用的物理內存的大小 VmRSS/4
Shared(pages) 共享頁數 0
Trs(pages) 程序所擁有的可執行虛擬內存的大小 VmExe/4
Lrs(pages) 被映像到任務的虛擬內存空間的庫的大小 VmLib/4
Drs(pages) 程序數據段和用戶態的棧的大小 （VmData+ VmStk ）4
dt(pages) 04
查看機器可用內存
/proc/28248/>free
total used free shared buffers cached
Mem: 1023788 926400 97388 0 134668 503688
-/+ buffers/cache: 288044 735744
Swap: 1959920 89608 1870312
我們通過free命令查看機器空閑內存時，會發現free的值很小。這主要是因為，在linux中有這么一種思想，內存不用白不用，因此它盡可能的cache和buffer一些數據，以方便下次使用。但實際上這些內存也是可以立刻拿來使用的。
所以 空閑內存=free+buffers+cached=total-used
top命令 是Linux下常用的性能 分析工具 ，能夠實時顯示系統 中各個進程的資源佔用狀況，類似於Windows的任務管理 器。下面詳細介紹它的使用方法。
top - 02:53:32 up 16 days, 6:34, 17 users, load average: 0.24, 0.21, 0.24
Tasks: 481 total, 3 running, 474 sleeping, 0 stopped, 4 zombie
Cpu(s): 10.3%us, 1.8%sy, 0.0%ni, 86.6%id, 0.5%wa, 0.2%hi, 0.6%si, 0.0%st
Mem: 4042764k total, 4001096k used, 41668k free, 383536k buffers
Swap: 2104472k total, 7900k used, 2096572k free, 1557040k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32497 jacky 20 0 669m 222m 31m R 10 5.6 29:27.62 firefox
4788 yiuwing 20 0 257m 18m 13m S 5 0.5 5:42.44 konsole
5657 Liuxiaof 20 0 585m 159m 30m S 4 4.0 5:25.06 firefox
4455 xiefc 20 0 542m 124m 30m R 4 3.1 7:23.03 firefox
6188 Liuxiaof 20 0 191m 17m 13m S 4 0.5 0:01.16 konsole
統計信息區前五行是系統整體的統計信息。第一行是任務隊列信息，同 uptime 命令的執行結果。其內容如下：
01:06:48 當前時間
up 1:22 系統運行 時間，格式為時:分
1 user 當前登錄用戶 數
load average: 0.06, 0.60, 0.48 系統負載 ，即任務隊列的平均長度。
三個數值分別為 1分鍾、5分鍾、15分鍾前到現在的平均值。
第二、三行為進程和CPU的信息。當有多個CPU時，這些內容可能會超過兩行。內容如下：
Tasks: 29 total 進程總數
1 running 正在運行的進程數
28 sleeping 睡眠的進程數
0 stopped 停止的進程數
0 zombie 僵屍進程數
Cpu(s): 0.3% us 用戶空間佔用CPU百分比
1.0% sy 內核 空間佔用CPU百分比
0.0% ni 用戶進程空間內改變過優先順序的進程佔用CPU百分比
98.7% id 空閑CPU百分比
0.0% wa 等待輸入輸出的CPU時間百分比
0.0% hi
0.0% si
最後兩行為內存 信息。內容如下：
Mem: 191272k total 物理內存總量
173656k used 使用的物理內存總量
17616k free 空閑內存總量
22052k buffers 用作內核緩存 的內存量
Swap: 192772k total 交換區總量
0k used 使用的交換區總量
192772k free 空閑交換區總量
123988k cached 緩沖的交換區總量。
內存中的內容被換出到交換區，而後又被換入到內存，但使用過的交換區尚未被覆蓋，
該數值即為這些內容已存在於內存中 的交換區的大小。
相應的內存再次被換出時可不必再對交換區寫入。
進程信息區統計信息區域的下方顯示了各個進程的詳細信息。首先來認識一下各列的含義。
序號 列名 含義
a PID 進程id
b PPID 父進程id
c RUSER Real user name
d UID 進程所有者的用戶id
e USER 進程所有者的用戶名
f GROUP 進程所有者的組名
g TTY 啟動進程的終端名。不是從終端啟動的進程則顯示為 ?
h PR 優先順序
i NI nice值。負值表示高優先順序，正值表示低優先順序
j P 最後使用的CPU，僅在多CPU環境 下有意義
k %CPU 上次更新到現在的CPU時間佔用百分比
l TIME 進程使用的CPU時間總計，單位秒
m TIME+ 進程使用的CPU時間總計，單位1/100秒
n %MEM 進程使用的物理內存 百分比
o VIRT 進程使用的虛擬內存總量，單位kb。VIRT=SWAP+RES
p SWAP 進程使用的虛擬內存中，被換出的大小，單位kb。
q RES 進程使用的、未被換出的物理內存大小，單位kb。RES=CODE+DATA
r CODE 可執行代碼佔用的物理 內存大小，單位kb
s DATA 可執行代碼以外的部分(數據 段+棧)佔用的物理 內存大小，單位kb
t SHR 共享內存大小，單位kb
u nFLT 頁面錯誤次數
v nDRT 最後一次寫入到現在，被修改過的頁面數。
w S 進程狀態。
D =不可中斷的睡眠狀態
R =運行
S =睡眠
T =跟蹤/停止
Z =僵屍進程
x COMMAND 命令名/命令行
y WCHAN 若該進程在睡眠，則顯示睡眠中的系統函數名
z Flags 任務標志，參考 sched.h
默認情況下僅顯示比較重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通過下面的快捷鍵來更改顯示內容。
更改顯示內容通過 f 鍵可以選擇顯示的內容。按 f 鍵之後會顯示列的列表，按 a-z 即可顯示或隱藏對應的列，最後按回車鍵確定。
按 o 鍵可以改變列的顯示順序。按小寫的 a-z 可以將相應的列向右移動，而大寫的 A-Z 可以將相應的列向左移動。最後按回車鍵確定。
按大寫的 F 或 O 鍵，然後按 a-z 可以將進程按照相應的列進行排序。而大寫的 R 鍵可以將當前的排序倒轉。
==============================
top命令使用過程中，還可以使用一些交互的命令來完成其它參數的功能。這些命令是通過快捷鍵啟動的。
＜空格＞：立刻刷新。
P：根據CPU使用大小進行排序。
T：根據時間、累計時間排序。
q：退出top命令。
m：切換顯示內存信息。
t：切換顯示進程和CPU狀態信息。
c：切換顯示命令名稱和完整命令行。
M：根據使用內存大小進行排序。
W：將當前設置寫入~/.toprc文件中。這是寫top配置文件的推薦方法。
可以看到，top命令是一個功能十分強大的監控系統的工具，對於系統管理員而言尤其重要。但是，它的缺點是會消耗很多系統資源。
應用實例
使用top命令可以監視指定用戶，預設情況是監視所有用戶的進程。如果想查看指定用戶的情況，在終端中按「U」鍵，然後輸入用戶名，系統就會切換為指定用戶的進程運行界面。
a.作用
free命令用來顯示內存的使用情況，使用許可權是所有用戶。
b.格式
free [－b－k－m] [－o] [－s delay] [－t] [－V]
c.主要參數
－b －k －m：分別以位元組（KB、MB）為單位顯示內存使用情況。
－s delay：顯示每隔多少秒數來顯示一次內存使用情況。
－t：顯示內存總和列。
－o：不顯示緩沖區調節列。
d.應用實例
free命令是用來查看內存使用情況的主要命令。和top命令相比，它的優點是使用簡單，並且只佔用很少的系統資源。通過－S參數可以使用free命令不間斷地監視有多少內存在使用，這樣可以把它當作一個方便實時監控器。
＃free －b －s5
使用這個命令後終端會連續不斷地報告內存使用情況（以位元組為單位），每5秒更新一次。
❽ 怎樣查看手機內存空間佔用情況
手機內存空間的查看，首先要知道你的是啥手機，比如蘋果手機和安卓手機吧。
首先來看蘋果手機。
1.點擊打開蘋果手機自帶的設置應用
2.進入手機的設置頁面後，找到並點擊「通用」設置進入。
3.在通過設置頁面中，點擊「儲存空間與ICloud用量」按鈕
4.跳轉到「儲存空間與ICloud用量」頁面後，即可看到目前手機儲存空間的使用情況。
5.想要查看或者刪除某一些具體的應用，點擊「管理儲存空間」進入查看。
6.進入管理儲存空間頁面後，可以根據自己的手機條件，刪除掉一些佔用比較大空間，而又不常用的應用。
對於安卓機：
1.打開設置，點擊「存儲」，可以看到手機內存、緩存數據等數據。
2.點擊「內存」，可以看到手機內存平均使用量、性能等，返回到設置界面。
3.點擊「系統」，點擊「關於手機」，可以看到關於手機的版本、處理器、運行內存等數據。
❾ 怎麼查看windows環境下伺服器內存的使用情況
用工具解決！
RamMap用於展示系統和進程內存狀態和利用率。它提供一個命名為「使用計數」的概要欄，它列出所有各種各樣的系統內存分區，如分頁池和非分頁池、流程私密的、可共享的、硬碟空間、內核堆棧和映射文件。它還顯示被稱為Metafile的緩存文件內存空間的數量。
如果你要解決的內存問題看起來和特定的進程或應用相關，你也許有必要通過使用VMMap來仔細看看。VMMap是一個過程導向的工具，它讓你可以查看現有的進程或者追蹤新的進程並查看其內存使用，它提供的信息遠比RamMap詳細。
VMMap啟動時，它提示你選擇你想要審查的現在進程或是開啟一個新的進程。如果你啟動了一個新進程，你將能追蹤內存利用率，如堆和虛擬分配。
❿ ucos 怎樣確定任務堆棧大小
1、首先需要知道，μC/OS-II中創建任務的函數有兩個: OSTaskCreate()和OSTaskCreateExt()
（1）OSTaskCreate()//創建普通任務
由於重點在下面的創建擴展任務函數，故本函數就不多說了！確實，要想實現檢測目標任務棧實際使用情況的功能，是不能使用這個函數來創建目標任務的，必須使用OSTaskCreateExt() 。
（2）OSTaskCreateExt() //創建擴展任務
函數介面原型為：
#if OS_TASK_CREATE_EXT_EN > 0
INT8U OSTaskCreateExt
(
void (*task)(void *pd), //建立擴展任務(任務代碼指針
void *pdata, //傳遞參數指針
OS_STK *ptos, //分配任務堆棧棧頂指針
INT8U prio, //分配任務優先順序
INT16U id, //(未來的)優先順序標識(與優先順序相同)
OS_STK *pbos, //分配任務堆棧棧底指針
INT32U stk_size, //指定堆棧的容量(檢驗用)
void *pext, //指向用戶附加的數據域的指針
INT16U opt //建立任務設定選項
)
#endif
2、其次需要知道μC/OS-II中有這么個函數：OSTaskStkChk()
不錯，檢測任務堆棧實際使用情況正是用的這個函數，下面來本函數的介面原型：
INT8U OSTaskStkChk
(
INT8U prio, //待測任務的優先順序
OS_STK_DATA *pdata //指向一個類型為OS_STK_DATA的結構體
)
3、再次需要知道一個結構體：
#if OS_TASK_CREATE_EXT_EN > 0
typedef struct
{
INT32U OSFree; //堆棧中未使用的位元組數
INT32U OSUsed; //堆棧中已使用的位元組數
} OS_STK_DATA;
#endif
參數: prio 為指定要獲取堆棧信息的任務優先順序，也可以指定參數OS_PRIO_SELF，獲取調用任務本身的
信息。
pdata 指向一個類型為OS_STK_DATA的數據結構，其中包含如下信息：
INT32U OSFree; // 堆棧中未使用的位元組數
INT32U OSUsed; // 堆棧中已使用的位元組數
4、有了上述三個知識點後就可以啦，具體方法為：
（1）將函數的最後一個參數opt 設置為：OS_TASK_OPT_STK_CHK | OS_TASK_OPT_STK_CLR
（2）定義一個變數：OS_STK_DATA StackBytes；
（3）調用函數OSTaskStkChk(TestTaskPRIO,&StackBytes)
（4）StackBytes.OSFree的值即為被測任務堆棧未使用的位元組數，
StackBytes.OSUsed的值即為被測任務堆棧已使用的位元組數。
5、需要設置宏：OS_TASK_OPT_STK_CLR為1
6、最後一點建議：
（1）將被測任務經歷最壞的堆棧使用狀態，測出來的使用率才可靠
（2）堆棧使用率最好在%50~%80之間，太小浪費空間，太大不安全
（3）最好在工程中單獨建立一個優先順序較低延時較長的任務來測試其它任務的堆棧使用情況，不用時可以掛起該任務
有時候決定任務實際所需的堆棧空間大小是很有必要的。因為這樣用戶就可以避免為任務分配過多的堆棧空間，從而減少自己的應用程序代碼所需的RAM(內存)數量。?C/OS-Ⅱ提供的OSTaskStkChk()函數可以為用戶提供這種有價值的信息。
在圖4.2中，筆者假定堆棧是從上往下遞減的(即OS_STK_GROWTH被置為1)，但以下的討論也同樣適用於從下往上長的堆棧[F4.2(1)]。?C/OS-Ⅱ是通過查看堆棧本身的內容來決定堆棧的方向的。只有內核或是任務發出堆棧檢驗的命令時，堆棧檢驗才會被執行，它不會自動地去不斷檢驗任務的堆棧使用情況。在堆棧檢驗時，?C/OS-Ⅱ要求在任務建立的時候堆棧中存儲的必須是0值(即堆棧被清零)[F4.2(2)]。另外，?C/OS-Ⅱ還需要知道堆棧棧底(BOS)的位置和分配給任務的堆棧的大小[F4.2(2)]。在任務建立的時候，BOS的位置及堆棧的這兩個值儲存在任務的OS_TCB中。
為了使用?C/OS-Ⅱ的堆棧檢驗功能，用戶必須要做以下幾件事情：
l在OS_CFG.H文件中設OS_TASK_CREATE_EXT為1。
l用OSTaskCreateExt()建立任務，並給予任務比實際需要更多的內存空間。
l在OSTaskCreateExt()中，將參數opt設置為OS_TASK_OPT_STK_CHK+OS_TASK_OPT_STK_
CLR。注意如果用戶的程序啟動代碼清除了所有的RAM，並且從未刪除過已建立了的任務，那麼用戶就不必設置選項OS_TASK_OPT_STK_CLR了。這樣就會減少OSTaskCreateExt()的執行時間。
l將用戶想檢驗的任務的優先順序作為OSTaskStkChk()的參數並調用之。
圖4.2堆棧檢驗
OSTaskStkChk()順著堆棧的棧底開始計算空閑的堆棧空間大小，具體實現方法是統計儲存值為0的連續堆棧入口的數目，直到發現儲存值不為0的堆棧入口[F4.2(5)]。注意堆棧入口的儲存值在進行檢驗時使用的是堆棧的數據類型(參看OS_CPU.H中的OS_STK)。換句話說，如果堆棧的入口有32位寬，對0值的比較也是按32位完成的。所用的堆棧的空間大小是指從用戶在OSTaskCreateExt()中定義的堆棧大小中減去了儲存值為0的連續堆棧入口以後的大小。OSTaskStkChk()實際上把空閑堆棧的位元組數和已用堆棧的位元組數放置在0S_STK_DATA數據結構中(參看?COS_Ⅱ.H)。注意在某個給定的時間，被檢驗的任務的堆棧指針可能會指向最初的堆棧棧頂(TOS)與堆棧最深處之間的任何位置[F4.2(7)]。每次在調用OSTaskStkChk()的時候，用戶也可能會因為任務還沒觸及堆棧的最深處而得到不同的堆棧的空閑空間數。
用戶應該使自己的應用程序運行足夠長的時間，並且經歷最壞的堆棧使用情況，這樣才能得到正確的數。一旦OSTaskStkChk()提供給用戶最壞情況下堆棧的需求，用戶就可以重新設置堆棧的最後容量了。為了適應系統以後的升級和擴展，用戶應該多分配10％－100％的堆棧空間。在堆棧檢驗中，用戶所得到的只是一個大致的堆棧使用情況，並不能說明堆棧使用的全部實際情況。
OSTaskStkChk()函數的代碼如程序清單L4.10所示。0S_STK_DATA(參看?COS_Ⅱ.H)數據結構用來保存有關任務堆棧的信息。筆者打算用一個數據結構來達到兩個目的。第一，把OSTaskStkChk()當作是查詢類型的函數，並且使所有的查詢函數用同樣的方法返回，即返回查詢數據到某個數據結構中。第二，在數據結構中傳遞數據使得筆者可以在不改變OSTaskStkChk()的API(應用程序編程介面)的條件下為該數據結構增加其它域，從而擴展OSTaskStkChk()的功能。現在，0S_STK_DATA只包含兩個域：OSFree和OSUsed。從代碼中用戶可看到，通過指定執行堆棧檢驗的任務的優先順序可以調用OSTaskStkChk()。如果用戶指定0S_PRIO_SELF[L4.10(1)]，那麼就表明用戶想知道當前任務的堆棧信息。當然，前提是任務已經存在[L4.10(2)]。要執行堆棧檢驗，用戶必須已用OSTaskCreateExt()建立了任務並且已經傳遞了選項OS_TASK_OPT_CHK[L4.10(3)]。如果所有的條件都滿足了，OSTaskStkChk()就會象前面描述的那樣從堆棧棧底開始統計堆棧的空閑空間[L4.10(4)]。最後，儲存在0S_STK_DATA中的信息就被確定下來了[L4.10(5)]。注意函數所確定的是堆棧的實際空閑位元組數和已被佔用的位元組數，而不是堆棧的總位元組數。當然，堆棧的實際大小(用位元組表示)就是該兩項之和。
程序清單L 4.10堆棧檢驗函數
INT8U OSTaskStkChk (INT8U prio, OS_STK_DATA *pdata)
{
OS_TCB*ptcb;
OS_STK*pchk;
INT32Ufree;
INT32Usize;
pdata->OSFree = 0;
pdata->OSUsed = 0;
if (prio > OS_LOWEST_PRIO && prio != OS_PRIO_SELF) {
return (OS_PRIO_INVALID);
}
OS_ENTER_CRITICAL();
if (prio == OS_PRIO_SELF) {(1)
prio = OSTCBCur->OSTCBPrio;
}
ptcb = OSTCBPrioTbl[prio];
if (ptcb == (OS_TCB *)0) {(2)
OS_EXIT_CRITICAL();
return (OS_TASK_NOT_EXIST);
}
if ((ptcb->OSTCBOpt & OS_TASK_OPT_STK_CHK) == 0) {(3)
OS_EXIT_CRITICAL();
return (OS_TASK_OPT_ERR);
}
free = 0;(4)
size = ptcb->OSTCBStkSize;
pchk = ptcb->OSTCBStkBottom;
OS_EXIT_CRITICAL();
#if OS_STK_GROWTH == 1
while (*pchk++ == 0) {
free++;
}
#else
while (*pchk-- == 0) {
free++;
}
#endif
pdata->OSFree = free * sizeof(OS_STK);(5)
pdata->OSUsed = (size - free) * sizeof(OS_STK);
return (OS_NO_ERR);
}
uCOS-III任務堆棧溢出檢測及統計任務堆棧使用量的方法
1. 在操作系統任務設計的時候，通常會遇到一個比較麻煩的問題，也就是任務堆棧大小設定的問題，為此我們我需要知道一些問題：
1.1. 任務堆棧一但溢出，意味著系統的崩潰，在有MMU或者MPU的系統中，對堆棧溢出的檢測十分簡單，因為這是MMU和MPU必備的功能之一。（uCOS-II/uCOS-III中均有針對沒有MMU和MPU的處理器對堆棧溢出檢測的策略）
1.2.堆棧的大小取決於該任務的需求。設定堆棧大小時，你就需要考慮：所有可能被堆棧調用的函數及其函數的嵌套層數，相關局部變數的大小，中斷服務程序所需要的空間。另外，堆棧還需存入CPU寄存器，如果處理器有浮點數單元FPU寄存器的話還需存入FPU寄存器。（PS：出於這點，所以在嵌入式系統中有個潛規則，避免寫遞歸函數）
1.3. 雖然任務堆棧大小可以通過人工計算出來，但是要考慮的太多，而且不能十分精確的計算。比如逐級嵌套被調用的函數的參數使用，上下文切換時候的CPU寄存器空間的保存，中斷時CPU寄存器空間的保存和中斷處理函數的堆棧空間等等，未免太過麻煩。特別的，當任務中使用了printf()之類參數可變的函數，那麼統計起來就更困難了。所以這種方式怎麼看怎麼不現實。囧 。
1.4. 建議在不是很精確的確定任務堆棧使用大小(stk_size)的情況下，還是採取stk_size乘以1.5或者2.0的做法，以保證任務的正常運行。
2. uCOS-III任務堆棧溢出檢測原理
每個任務都有自己的TCB(Task Control Block 任務控制塊)，TCB結構定義在uCOS-III源碼(我使用的是V3.03.00版本)中的os.h中。TCB中有個StkLimitPtr成員。
假設在切換到任務S前，代碼會檢測將要被載入CPU堆棧指針的值是否超出該任務S的TCB中StkLimitPtr限制。因為軟體不能在溢出時就迅速地做出反應，所以應該設置StkLimitPtr的值盡可能遠離&MyTaskStk[0]，保證有足夠的溢出緩沖。如下圖。軟體檢測不會像硬體檢測那樣有效，但也可以防止堆棧溢出。當uC/OS-III從一個任務切換到另一個任務的時候，它會調用一個hook函數OSTaskSwHook()，它允許用戶擴展上下文切換時的功能。所以，如果處理器沒有硬體支持溢出檢測功能，就可以在該hook函數中添加代碼軟體模擬該能。
不過我個人的做法是，通常設置StkLimitPtr指向任務棧大小的90%處，然後獲取任務堆棧使用量，如果棧使用率大於90%時就必須做出警告了！下面就來介紹任務棧使用量的獲取。
圖1
3. uCOS-III任務堆棧使用量統計的原理和方法
3.1 原理
原理其實很簡單，就是統計連續為0的區域的大小就可以知道空閑棧free的大小，而任務在創建時任務棧總量TaskStkSize是確定的，那麼使用了的棧大小used =TaskStkSize - free。見圖2。
圖2
首先，當任務創建時其堆棧被清零。然後，通過一個低優先順序任務，計算該任務整個堆棧中值為0的內存大小。如果發現都不為0，那麼就需要擴展堆棧的大小。然後，調整堆棧為的相應大小。這是一種非常有效的方法。注意的是，程序需用運行很長的時間以讓堆棧達到其需要的最大值。
3.2 方法
uC/OS-III提供了一個函數OSTaskStkChk()用於實現這個計算功能。那麼就來看看具體怎麼做吧。
3.2.1 首先創建一個任務來運行任務堆棧統計工作，值得注意的是，這個任務的優先順序建議設置為系統所有任務中最低的一個！
#define SystemDatasBroadcast_PRIO 12 // 統計任務優先順序最低，我這里是12，已經低於其他任務的優先順序了#define SystemDatasBroadcast_STK_SIZE 100 // 任務的堆棧大小，做統計一般夠了，統計結果出來後不夠再加..OS_TCB SystemDatasBroadcast_TCB; // 定義統計任務的TCBCPU_STK SystemDatasBroadcast_STK [SystemDatasBroadcast_STK_SIZE];// 開辟數組作為任務棧給任務使用static void AppTaskCreate(void){ // .....
// 這是系統創建任務的函數，還有其他任務創建的代碼，這里就不貼出了
// .....
OSTaskCreate( (OS_TCB *)&SystemDatasBroadcast_TCB,
(CPU_CHAR *)"SystemDatasBroadcast",
(OS_TASK_PTR ) SystemDatasBroadcast,
(void *) 0,
(OS_PRIO ) SystemDatasBroadcast_PRIO,
(CPU_STK *)&SystemDatasBroadcast_STK[0],
(CPU_STK_SIZE) SystemDatasBroadcast_STK_SIZE/10,/*棧溢出臨界值我設置在棧大小的90%處*/
(CPU_STK_SIZE) SystemDatasBroadcast_STK_SIZE,
(OS_MSG_QTY ) 0,
(OS_TICK ) 0,
(void *) 0,
(OS_OPT )(OS_OPT_TASK_STK_CHK | OS_OPT_TASK_STK_CLR),
(OS_ERR *) &err);
}
3.2.2 然後在任務函數SystemDatasBroadcast()中開始統計各個任務(其他任務的代碼就不貼了，跟
SystemDatasBroadcast創建代碼的方法是一模一樣的，大家根據自己的需求照葫蘆畫瓢即可)的棧使用,代碼如下：
void SystemDatasBroadcast (void *p_arg){
OS_ERR err;
CPU_STK_SIZE free,used;
(void)p_arg; while(DEF_TRUE)
{
OSTaskStkChk (&SystemDatasBroadcast_TCB,&free,&used,&err); printf("SystemDatasBroadcast used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
OSTaskStkChk (&Core_Page_TCB,&free,&used,&err); printf("Core_Page used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
OSTaskStkChk (&GUIActive_TCB,&free,&used,&err); printf("GUIActive used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
OSTaskStkChk (&KeyCheck_Process_TCB,&free,&used,&err); printf("KeyCheck used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
OSTaskStkChk (&Light_Adjust_TCB,&free,&used,&err); printf("Light_Adjust used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
OSTaskStkChk (&Calibrate_Process_TCB,&free,&used,&err); printf("Calibrate used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
OSTaskStkChk (&Data_Process_TCB,&free,&used,&err); printf("Data_Process used/free:%d/%d usage:%%%d
",used,free,(used*100)/(used+free));
printf("
");
OSTimeDlyHMSM(0,0,5,0,(OS_OPT)OS_OPT_TIME_DLY,(OS_ERR*)&err);
}
}
3.2.3實驗結果
上述代碼的實驗結果如下圖所示，可以清楚的看到每個任務的堆棧的使用狀況。
但是請遵循一個原則：必須讓系統運行足夠久，比如盡量讓系統處於不同的運行狀態下，然後觀察任務堆棧使用的變化，找到堆棧的最高使用率，然後根據上文所說的原則按需重新分配新的任務堆棧大小。