❶ 查看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实验结果
上述代码的实验结果如下图所示，可以清楚的看到每个任务的堆栈的使用状况。
但是请遵循一个原则：必须让系统运行足够久，比如尽量让系统处于不同的运行状态下，然后观察任务堆栈使用的变化，找到堆栈的最高使用率，然后根据上文所说的原则按需重新分配新的任务堆栈大小。