1. 为什么QNX内存分析绕不开pmap这个工具
搞嵌入式系统的朋友对QNX应该不陌生，它在汽车座舱、工业控制、医疗设备这些对实时性和可靠性要求极高的场景里出场率非常高。但很多人第一次接触QNX内存分析时，会习惯性地把Linux那套free、top、vmstat的思路直接搬过来，结果发现根本对不上号。QNX的内存管理模型和Linux差异很大，尤其是微内核架构下，内存的分配、映射、共享机制都有自己的一套逻辑。这个时候，pmap就成了你手里最趁手的一把解剖刀。
这篇文章主要面向已经在QNX平台上做开发或者系统调优的工程师，尤其是那些遇到内存泄漏、内存碎片、进程异常增长但不知道从哪儿下手的同学。我会把pmap这个工具的用法、输出解读、实战排查思路完整地拆一遍，顺便把QNX内存管理的核心概念串起来讲清楚。你不需要有很深的内核背景，但至少要能跑QNX的命令行，知道什么是进程、什么是虚拟地址空间。
先说结论：pmap在QNX下的定位和Linux下的pmap有相似之处，但输出格式、字段含义、可用的参数都不一样。QNX的pmap更偏向于展示进程的地址空间映射细节，包括代码段、数据段、堆、栈、共享库、匿名映射等各个区域的起始地址、大小、权限和映射类型。掌握它，你就能像看X光片一样，把一个进程的内存布局看得清清楚楚。
我见过太多人遇到内存问题就只会重启进程，或者盲目加内存。其实大部分时候，问题出在某个动态库反复加载卸载、某个线程栈溢出、或者堆区碎片化严重。这些用pmap都能快速定位。接下来我会从QNX内存管理的基础模型讲起，然后逐层深入到pmap的每个字段、每个参数，最后给出一套完整的排查流程和实战案例。
1.1 QNX微内核下的内存管理模型和Linux有什么不同
要理解pmap的输出，先得搞清楚QNX的内存管理到底是怎么一回事。QNX是微内核架构，内核只负责最基础的调度、IPC、中断处理，内存管理的大部分工作其实是由进程管理器（process manager）和各个资源管理器协作完成的。这和Linux宏内核把内存管理、文件系统、网络协议栈都塞进内核空间的做法完全不同。
在QNX里，每个进程都有自己独立的虚拟地址空间，这一点和Linux一样。但QNX的地址空间划分更“扁平”，没有Linux那种复杂的区域（zone）、节点（node）概念。QNX把进程的地址空间分成几个大的段：代码段（text）、数据段（data）、堆（heap）、栈（stack）、以及各种映射区域（mappings）。pmap就是把这些段和映射区域一一列出来。
另一个关键差异是QNX的共享内存机制。QNX大量使用共享内存来做进程间通信，比如shm_open创建的共享内存对象、mmap映射的文件、以及系统内部的共享库。这些在pmap输出里都会体现为独立的映射条目。如果你发现某个进程的映射条目特别多，那大概率是共享库加载过多或者共享内存没释放。
还有一点，QNX的堆管理用的是自己的malloc实现，和Linux的glibc malloc不一样。QNX的堆增长策略、碎片处理方式都有独特之处。pmap能告诉你堆的当前大小和起始地址，但具体堆内部怎么分配的，还得结合malloc的调试工具来看。
注意：QNX不同版本（6.5、6.6、7.0、7.1、8.0）的
pmap输出格式有细微差别，字段名称和排列顺序可能不同。本文以QNX 7.1为主，其他版本我会在关键处标注差异。
1.2 pmap能解决哪些实际排查场景
很多人问，我直接用pidin看进程内存不就行了吗？pidin确实能给出进程的内存总量，比如代码段多大、数据段多大、堆栈各占多少。但它给的是汇总值，看不到具体的映射分布。当你需要回答下面这些问题时，pmap才是正确答案：
- 某个进程为什么虚拟内存占用比物理内存大那么多？是哪些映射区域导致的？
- 共享库加载了哪些？每个库占了多少地址空间？
- 堆区是不是碎片化了？堆的起始地址和结束地址之间有没有大量未使用的空洞？
- 某个线程的栈是不是快溢出了？栈的映射区域有多大？
- 有没有匿名映射泄漏？比如
mmap之后忘记munmap？ - 共享内存对象有没有正确释放？映射的物理地址是什么？
这些问题在pidin的输出里要么看不到，要么只能看到汇总数字。而pmap能给你逐条映射的明细，精确到每个区域的起始地址、大小、权限、偏移量和映射类型。有了这些信息，你就能判断内存到底被谁吃了。
我个人的经验是，排查QNX内存问题，先用pidin看总量，发现异常后再用pmap看明细，最后结合hogs、showmem等工具交叉验证。这套组合拳打下来，90%的内存问题都能定位到具体原因。
2. pmap命令的完整参数解析和输出字段详解
pmap的基本用法很简单，直接跟进程ID就行。但要想真正用好它，必须把每个参数和每个输出字段都吃透。这一章我会把pmap的所有常用参数、输出格式、字段含义逐一拆解，并给出实际示例。
2.1 基础用法和常用参数速查
先看最基本的命令格式：
pmap [options] pid不带任何参数时，pmap会输出指定进程的完整地址空间映射列表。但实际排查时，我们通常会加一些参数来过滤或改变输出格式。下面这张表是我整理的常用参数速查：
| 参数 | 作用 | 适用场景 |
|---|---|---|
-a | 显示所有映射，包括系统保留区域 | 需要看完整地址空间布局时 |
-h | 以人类可读格式显示大小（KB、MB） | 快速判断区域大小 |
-n | 只显示匿名映射 | 排查堆和匿名内存泄漏 |
-s | 只显示共享映射 | 排查共享库和共享内存 |
-f | 显示文件映射的完整路径 | 定位具体是哪个库或文件 |
-p | 显示权限标志的详细解释 | 确认内存区域是否可读写执行 |
-v | 详细模式，显示更多内部信息 | 深度分析时使用 |
-r | 显示物理地址映射 | 需要知道虚拟地址对应的物理地址时 |
这些参数可以组合使用，比如pmap -h -f -p 12345会以人类可读格式显示完整文件路径和权限解释。我一般习惯先用pmap -h pid看整体，再用pmap -n -h pid专门看匿名映射。
提示：QNX 7.1的
pmap还支持-S参数按大小排序，这在映射条目很多时非常有用。QNX 6.6及更早版本没有这个参数，需要手动排序。
2.2 输出字段逐列解读
pmap的默认输出通常包含以下几列，不同版本可能略有差异，但核心字段是一致的：
START END SIZE PERM OFFSET MAPPING 00010000 00020000 00010000 r-x 00000000 /proc/boot/procnto 00020000 00030000 00010000 rw- 00000000 /proc/boot/procnto ...START和END：映射区域的起始和结束虚拟地址。这两个值都是十六进制，单位是字节。通过END - START就能算出区域大小。注意QNX的地址空间布局和Linux不同，起始地址通常从0x00010000附近开始，而不是Linux常见的0x08048000。
SIZE：区域大小，十六进制表示。如果加了-h参数，会显示成4K、64K、1M这种人类可读格式。我强烈建议日常排查都加-h，不然你还得自己换算。
PERM：权限标志，三个字符分别代表读、写、执行。r-x表示可读可执行但不可写，通常是代码段；rw-表示可读可写不可执行，通常是数据段和堆；rwx表示可读可写可执行，这种区域要特别小心，可能是JIT编译器的代码缓存或者某些特殊映射。
OFFSET：文件映射的偏移量。对于文件映射区域，这个值表示从文件开头算起的偏移。对于匿名映射，这个值通常是00000000。
MAPPING：映射的来源。可能是文件路径（如/proc/boot/procnto）、共享内存对象名（如/dev/shmem/xxx）、或者[anon]表示匿名映射。加了-f参数后，文件路径会显示完整路径，不加的话可能只显示文件名。
还有一个容易被忽略的字段是DEV（设备号）和INO（inode号），在某些QNX版本中会显示。这两个字段对于区分同名但不同实例的共享内存对象很有用。
2.3 不同QNX版本的输出差异和兼容性处理
QNX 6.5、6.6、7.0、7.1、8.0的pmap输出格式有一些差异，我整理了一个对比表：
| 版本 | 字段差异 | 参数差异 | 注意事项 |
|---|---|---|---|
| QNX 6.5 | 无-h参数，SIZE为十六进制 | 参数较少 | 需要手动换算大小 |
| QNX 6.6 | 增加-h参数 | 增加-n、-s | 输出格式基本稳定 |
| QNX 7.0 | 增加-p权限解释 | 增加-v详细模式 | 字段顺序有调整 |
| QNX 7.1 | 增加-S排序 | 参数最全 | 推荐使用此版本 |
| QNX 8.0 | 输出格式微调 | 兼容7.1 | 注意新增字段 |
如果你在维护跨版本的项目，建议写脚本时不要硬编码字段位置，而是用awk按列名匹配。比如：
pmap -h $PID | awk '/^[0-9a-f]/ {print $1, $2, $3, $4, $6}'这样即使字段顺序变了，只要列名不变，脚本还能用。
3. 从pmap输出中读懂QNX进程的内存布局
光知道字段含义还不够，关键是要能从一堆映射条目里看出门道。这一章我会结合一个真实的QNX进程pmap输出，逐段分析它的内存布局，告诉你哪些区域是正常的，哪些区域可能有问题。
3.1 代码段、数据段、堆、栈的典型分布
先看一个典型的QNX进程pmap输出（已简化）：
START END SIZE PERM MAPPING 00010000 00040000 30000 r-x /proc/boot/myapp 00040000 00042000 2000 rw- /proc/boot/myapp 00042000 00082000 40000 rw- [anon] (heap) 00082000 000a2000 20000 rw- [anon] (stack) ...第一行是代码段，权限r-x，映射到可执行文件/proc/boot/myapp。第二行是数据段，权限rw-，同样映射到该文件。注意数据段的大小通常比代码段小很多，如果数据段异常大，可能是全局变量或静态数组定义过多。
第三行是堆区，标记为[anon]，权限rw-。堆的起始地址紧跟在数据段之后，这是QNX的典型布局。堆的大小会随着malloc调用动态增长，但pmap显示的是当前已映射的大小，不是实际使用量。如果堆的SIZE远大于你预期的分配量，说明堆碎片化严重或者有内存泄漏。
第四行是主线程栈，也是[anon]，权限rw-。QNX的默认线程栈大小通常是128KB或256KB，具体取决于版本和配置。如果栈的SIZE接近这个值，说明栈快满了，需要警惕栈溢出。
注意：QNX的栈是向下增长的，
START是高地址，END是低地址。这和Linux一样，但QNX的栈映射区域在pmap里显示的顺序可能和实际增长方向相反，解读时要留意。
3.2 共享库和共享内存映射的识别方法
共享库在pmap输出里通常表现为多个连续的映射条目，每个条目对应库的不同段（代码段、数据段、只读数据段等）。比如：
START END SIZE PERM MAPPING 00100000 00120000 20000 r-x /usr/lib/libc.so.4 00120000 00122000 2000 rw- /usr/lib/libc.so.4 00122000 00124000 2000 r-- /usr/lib/libc.so.4同一个库出现三次，分别对应代码段、数据段和只读数据段。这是正常现象。如果你发现某个库的映射条目特别多，或者同一个库被多个进程重复映射，那就要考虑是不是动态加载/卸载逻辑有问题。
共享内存的识别稍微复杂一些。QNX的共享内存对象通常映射为/dev/shmem/xxx或者/dev/shm/xxx，具体路径取决于创建方式。比如：
START END SIZE PERM MAPPING 00200000 00210000 10000 rw- /dev/shmem/my_shm如果看到大量/dev/shmem/开头的映射，说明进程在使用共享内存做IPC。这时候要检查每个共享内存对象是否在进程退出时正确munmap和shm_unlink，否则会造成共享内存泄漏。
还有一种情况是匿名共享映射，显示为[anon]但权限是rw-s（带s表示共享）。这种通常是mmap时指定了MAP_SHARED但没有文件后端。这种映射如果忘记释放，排查起来更麻烦，因为看不到名字。
3.3 匿名映射和文件映射的区分技巧
匿名映射和文件映射在pmap输出里的区别主要看MAPPING列。文件映射会显示文件路径或设备名，匿名映射显示[anon]。但有些情况下，文件映射的路径可能被截断或者显示为[unknown]，这时候需要加-f参数看完整路径。
另外，匿名映射的OFFSET列通常是00000000，而文件映射的OFFSET可能非零。但这不是绝对的，有些文件映射的偏移量也是零。最可靠的区分方法还是看MAPPING列。
我个人的经验是，排查内存泄漏时，重点关注匿名映射和共享内存映射。文件映射通常有明确的来源，不容易泄漏。而匿名映射和共享内存映射如果管理不当，很容易出现只增不减的情况。
4. 实战：用pmap定位三类典型内存问题
理论讲完了，这一章直接上实战。我会用三个真实案例，分别演示如何用pmap定位堆内存泄漏、共享库重复加载、以及线程栈溢出问题。每个案例都包含完整的排查步骤、命令输出和结论分析。
4.1 案例一：堆内存持续增长但pidin显示正常
问题现象：某QNX进程运行24小时后，pidin显示堆大小从初始的2MB增长到50MB，但进程实际处理的请求量并没有明显增加。重启进程后堆大小恢复，但几小时后又开始增长。
排查步骤：
第一步，先用pidin确认堆的总体情况：
pidin -p 12345 mem输出显示堆区大小为50MB，但数据段只有1MB，代码段2MB。堆区异常大。
第二步，用pmap看堆区的详细映射：
pmap -h -n 12345输出中堆区显示为多个连续的[anon]映射，总大小50MB。但奇怪的是，这些映射的权限都是rw-，没有rwx，说明不是JIT代码缓存。
第三步，用pmap -v看更详细的信息：
pmap -v -n 12345详细模式显示每个匿名映射的创建时间戳和调用栈（如果编译时开启了调试信息）。发现大量映射是在处理某个特定请求时创建的，但请求结束后没有释放。
结论：代码中有一处malloc之后在错误处理分支里忘记free，导致每次请求都泄漏一小块内存。24小时累积下来就是50MB。
修复方法：在错误处理分支加上free，并用pmap验证修复后堆大小稳定在2MB左右。
实操心得：
pmap -v的时间戳信息非常有用，能帮你把内存分配和具体操作关联起来。但前提是编译时加了-g选项，否则看不到调用栈。
4.2 案例二：共享库重复加载导致地址空间碎片化
问题现象：某进程启动后虚拟地址空间占用达到800MB，但实际物理内存只用了100MB。pidin显示映射条目超过2000个。
排查步骤：
第一步，用pmap -s -h只看共享映射：
pmap -s -h 12345 | head -50发现同一个共享库libfoo.so出现了几十次，每次的起始地址都不同。
第二步，统计每个库的映射次数：
pmap -s -h 12345 | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20输出显示libfoo.so被映射了48次，libbar.so被映射了32次。
第三步，检查代码中的dlopen和dlclose调用。发现某个循环里每次迭代都dlopen同一个库，但只在循环结束后dlclose一次。由于dlopen的引用计数机制，每次dlopen都会增加引用计数，但地址空间映射是每次都会新增的。
结论：dlopen调用位置不当，导致同一个库被反复映射到不同地址。虽然物理内存是共享的，但虚拟地址空间被大量占用，最终可能导致地址空间耗尽。
修复方法：把dlopen移到循环外面，只加载一次。修复后映射条目从2000多个降到200多个。
注意：QNX的
dlopen默认使用RTLD_LOCAL，每次调用都会创建新的映射。如果确实需要多次打开同一个库，考虑用RTLD_GLOBAL或者手动管理引用计数。
4.3 案例三：线程栈溢出前的pmap预警信号
问题现象：某多线程进程偶尔崩溃，崩溃日志显示SIGSEGV，但堆栈信息不完整。怀疑是线程栈溢出。
排查步骤：
第一步，用pmap -h查看所有栈映射：
pmap -h 12345 | grep -i stack输出显示主线程栈大小为256KB，但有几个工作线程的栈只有64KB。
第二步，检查线程创建时的栈大小设置。发现代码中pthread_attr_setstacksize设置的是64KB，但线程函数里有一个大的局部数组，占用约60KB。
第三步，用pmap持续监控栈的使用情况。在栈映射区域，START和END之间的空间是已映射的，但实际使用量需要结合栈指针来判断。QNX的pmap不直接显示栈指针，但可以通过pidin -p 12345 -F查看线程的栈指针位置。
结论：线程栈设置过小，局部数组几乎占满整个栈，稍微深一点的函数调用就会溢出。
修复方法：把线程栈大小调整为256KB，并在代码规范里明确禁止在栈上分配大数组。
实操心得：QNX的默认线程栈大小可以通过环境变量
THREAD_STACK_SIZE调整，但更推荐在pthread_attr_setstacksize里显式设置。另外，可以用pmap定期采样，观察栈映射区域是否在缩小（栈增长），如果持续缩小，说明栈使用量在增加，需要警惕。
5. pmap与其他QNX内存工具的配合使用
pmap虽然强大，但不是万能的。有些信息它给不了，需要和其他工具配合。这一章我会介绍pidin、hogs、showmem、malloc调试工具等与pmap的配合方式，形成一套完整的内存分析工具箱。
5.1 pidin和pmap的分工与协作
pidin是QNX下最常用的进程信息工具，它的mem子命令能给出进程内存的汇总信息：
pidin -p 12345 mem输出包括代码段、数据段、堆、栈的总大小。这个汇总信息适合快速判断哪个区域异常。比如堆异常大，就用pmap -n看堆的明细；栈异常大，就用pmap看栈映射。
pidin还有一个-F参数，能显示每个线程的详细信息，包括栈指针、寄存器状态等。这个在排查栈溢出时非常有用。
我通常的流程是：pidin mem看汇总 -> 发现异常区域 ->pmap看明细 ->pidin -F看线程状态 -> 定位问题。
5.2 hogs和showmem在内存压力分析中的角色
hogs是QNX下的资源占用查看工具，能按CPU、内存、文件描述符等维度排序显示进程。当系统整体内存紧张时，先用hogs找出内存占用最大的几个进程，再对这些进程用pmap深入分析。
hogs -m -n 10这条命令显示内存占用前10的进程。注意hogs显示的是物理内存占用，而pmap显示的是虚拟地址空间。两者结合，能区分是虚拟内存泄漏还是物理内存泄漏。
showmem则更偏向于系统级的内存统计，能显示物理内存总量、已用量、缓存量、交换量等。QNX通常不启用交换，所以物理内存用尽就是真的用尽了。showmem的输出能帮你判断是单个进程的问题还是系统整体的问题。
5.3 malloc调试工具与pmap的交叉验证
QNX提供了malloc调试功能，可以通过环境变量启用：
export MALLOC_DEBUG=1 export MALLOC_TRACE=1启用后，malloc和free的每次调用都会记录到日志中。结合pmap的堆映射信息，可以精确追踪到哪次malloc没有对应的free。
具体做法是：先用pmap -n确认堆的起始地址和大小，然后在malloc日志里搜索这个地址范围内的分配记录。如果发现某个地址被分配后从未释放，那就是泄漏点。
提示：
MALLOC_DEBUG会显著降低性能，只建议在排查阶段临时启用。生产环境不要开。
6. 高频问题排查速查表和避坑指南
这一章我把实际工作中遇到的高频问题整理成速查表，并附上我踩过的坑和总结的技巧。这部分内容在官方文档里找不到，都是实战中积累的。
6.1 pmap输出异常速查表
| 异常现象 | 可能原因 | 排查命令 | 解决方法 |
|---|---|---|---|
| 堆区持续增长 | 内存泄漏 | pmap -n -h | 检查malloc/free配对 |
| 映射条目过多 | 共享库重复加载 | pmap -s -h | wc -l | 检查dlopen调用位置 |
| 栈区接近满 | 栈溢出风险 | pmap -h | grep stack | 增大线程栈或减少局部变量 |
大量[anon]映射 | 匿名mmap泄漏 | pmap -n -h | 检查mmap/munmap配对 |
| 共享内存不释放 | shm泄漏 | pmap | grep shmem | 检查shm_unlink调用 |
权限为rwx的区域 | JIT或特殊映射 | pmap -p | 确认是否必要，否则收紧权限 |
| 地址空间碎片化 | 频繁映射/解映射 | pmap -h | awk '{print $1}' | 优化映射策略，使用内存池 |
6.2 我踩过的五个坑和对应技巧
坑一：把虚拟内存占用当成物理内存占用。pmap显示的是虚拟地址空间，不是物理内存。一个进程可能虚拟内存占用1GB，但物理内存只用了50MB。排查内存压力时，一定要用hogs或showmem确认物理内存使用量。
技巧：pmap输出里，只有被实际访问过的页面才会占用物理内存。所以虚拟内存大不一定有问题，关键看物理内存。
坑二：忽略共享库的只读映射。共享库通常有三个映射：代码段（r-x）、数据段（rw-）、只读数据段（r--）。很多人只关注前两个，忽略了只读数据段。如果只读数据段异常大，可能是库的常量数据过多。
技巧：用pmap -s -h | awk '{sum+=$3} END {print sum}'统计所有共享库的总大小，和pidin的汇总值对比。
坑三：在QNX 6.5上用7.1的参数。QNX 6.5的pmap不支持-h、-n、-s等参数，强行使用会报错。跨版本维护时，先确认版本再写脚本。
技巧：用uname -a确认QNX版本，然后在脚本里做条件判断。
坑四：忘记pmap需要root权限。在某些QNX配置下，普通用户只能查看自己的进程，查看系统进程需要root权限。如果pmap报权限错误，先su到root。
技巧：生产环境建议用setuid或者配置权限，避免每次都要root。
坑五：把pmap输出直接贴到Excel里分析。pmap输出是十六进制，Excel默认按十进制解析，会导致大小计算错误。
技巧：用pmap -h输出人类可读格式，或者用awk的strtonum函数转换十六进制。
6.3 生产环境使用pmap的注意事项
在生产环境用pmap要特别小心，因为pmap需要读取进程的地址空间信息，可能会短暂暂停进程（取决于QNX版本和配置）。对于实时性要求极高的进程，建议在维护窗口执行。
另外，pmap的输出可能非常大，尤其是映射条目多的进程。建议重定向到文件再分析，不要直接在终端刷屏。
pmap -h -f 12345 > /tmp/pmap_12345.txt还有一点，pmap的输出是瞬时的，反映的是执行那一刻的状态。如果要观察内存变化趋势，需要定期采样：
while true; do pmap -h 12345 | md5sum; sleep 5; done通过比较每次的md5值，能快速判断内存布局是否在变化。
7. 从pmap出发构建QNX内存监控体系
单次pmap排查只能解决眼前问题，要真正管好QNX内存，需要建立一套监控体系。这一章我会分享如何把pmap集成到日常监控中，以及如何用脚本自动化分析。
7.1 定期采样和趋势分析脚本
我写了一个简单的采样脚本，每5分钟记录一次关键进程的pmap汇总信息：
#!/bin/sh PID=$1 LOGFILE=/var/log/pmap_${PID}.log while true; do echo "=== $(date) ===" >> $LOGFILE pmap -h $PID | awk '/^[0-9a-f]/ { total += strtonum("0x" $3) } END { printf "Total mappings: %d, Total size: %.2f MB\n", NR, total/1024/1024 }' >> $LOGFILE sleep 300 done这个脚本记录映射条目总数和总大小。如果总大小持续增长，说明有泄漏；如果条目数持续增长，说明有重复映射。
7.2 内存泄漏的早期预警指标
根据我的经验，以下几个指标可以作为内存泄漏的早期预警：
- 堆区大小连续3次采样增长超过10%
- 匿名映射条目数连续增长
- 共享内存映射条目只增不减
- 总映射条目数超过500（对于普通应用）
一旦触发这些指标，就自动用pmap -v抓取详细快照，并通知开发人员。
7.3 把pmap分析纳入CI/CD流程
对于长期运行的QNX应用，可以在CI/CD里加入内存检查步骤。比如在自动化测试跑完后，用pmap检查测试进程的内存布局，和基线对比。如果偏差超过阈值，就标记为失败。
具体做法是：在测试脚本最后加一行：
pmap -h $TEST_PID | awk '{sum+=$3} END {print sum}' > /tmp/mem_usage.txt然后和基线文件对比。这个方法能提前发现代码变更引入的内存问题，避免带到生产环境。
我个人在实际操作中的体会是，QNX内存问题最怕的就是“温水煮青蛙”——每次泄漏一点点，几天后才爆发。有了pmap加上自动化监控，就能在问题还小的时候及时发现。另外，不要迷信工具，pmap给的是数据，真正的判断还得靠你对业务代码的理解。多看看pmap输出，慢慢就能培养出对内存布局的直觉，一眼就能看出哪里不对劲。
