1. 项目概述：从“能用”到“精通”的内核日志调试

搞Linux驱动开发或者内核模块调试，printk这个函数你肯定不陌生。它就像嵌入在内核世界里的“嘴巴”，是我们窥探系统内部运行状态最直接的工具。但说实话，我见过太多开发者，包括早期的我自己，对printk的使用还停留在“能打印出来就行”的初级阶段。结果就是，在调试像RK3588这样复杂的SoC平台时，面对内核启动时刷屏的海量信息，关键的错误日志瞬间就被淹没，定位一个问题要花上大半天，效率极低。

问题的核心在于，printk不仅仅是一个打印函数，它背后是一套完整的日志优先级管理系统。真正玩转printk，意味着你能精准控制什么信息该在什么时候、以什么方式呈现。这就像给你的调试工具装上了“显微镜”和“过滤器”，既能放大关键细节，又能屏蔽无关噪音。今天，我们就抛开那些泛泛而谈的介绍，深入Linux内核（以常见的6.1版本为例，RK3588等平台常用）的日志机制腹地，把printk从参数解析、等级配置到实战避坑，一次彻底讲透。无论你是正在和RK3588的Device Tree、PCIe驱动搏斗，还是在调试任何Linux内核模块，这套方法都能让你的调试效率提升一个数量级。

2. 内核日志的基石：printk与printf的本质分野

很多从用户态编程转向内核开发的工程师，第一个困惑就是：为什么不能用熟悉的 printf ，而非要用 printk ？这个问题的答案，正是理解内核调试逻辑的起点。

2.1 运行环境的根本差异

printf 是C标准库（glibc等）提供的函数，它运行在用户态。它输出的目的地是标准输出（stdout），通常关联着你当前的终端或控制台。这个过程的路径相对清晰和“安全”。

而 printk 是Linux内核自身实现的一套日志输出机制。它运行在内核态，一个没有标准库、内存管理更为严格、且随时可能发生中断或调度的环境。内核态不能直接调用用户态的库函数。更重要的是，内核日志的受众和目的也不同：它需要记录系统生命周期内的所有关键事件，从启动、运行到崩溃，并且这些日志需要能被多种方式获取（如控制台、 dmesg 、日志文件），甚至在系统部分功能异常时也能工作。

2.2 printk的核心设计：优先级标签系统

如果内核里的每一个打印语句都像 printf 一样无条件地、立即地冲向控制台，那将是灾难性的。想象一下，驱动里每个函数的进入退出、每个变量的中间值都打印出来，系统真正的错误和警告瞬间就看不到了。因此， printk 最核心的设计就是引入了 日志等级（Log Level） 。

每一个 printk 语句都需要（或可以）附带一个优先级标签。这个标签决定了：

  1. 这条信息的重要性如何？ 是导致系统崩溃的紧急事件，还是仅供开发者深究的调试细节？
  2. 这条信息应该被送往何处？ 是立即显示在当前控制台上，还是先安静地躺在内核的环形缓冲区里，等待 dmesg 命令来查阅？

这套机制解决了内核调试的两个核心痛点： 信息重要性分层 和 输出渠道可控 。它确保了你不会在寻找一个“驱动加载失败”的致命错误时，被无数个“内存分配成功”的调试信息干扰视线。

3. 深入日志等级：8个级别的精准定义与应用场景

Linux内核为 printk 定义了8个标准的日志等级，在头文件``中通常以宏的形式定义。这里有一个关键且容易混淆的点： 等级数值越小，代表优先级越高，情况越紧急 。这个顺序和很多系统“数值越大越重要”的直觉相反，需要牢记。

以下表格详细拆解了这8个等级，我会结合RK3588这类嵌入式平台开发中常见的场景来举例说明，让你对每个等级该用在何处有更感性的认识。

等级宏定义 数值 英文含义 中文说明 典型应用场景与举例
KERN_EMERG 0 system is unusable 紧急（系统不可用） 系统即将崩溃或已经崩溃。例如：内核发生无法恢复的Oops/Panic，关键硬件（如CPU、内存）检测到不可纠正的错误。在RK3588启动中，如果DDR初始化完全失败，就可能用到此级别。 实践中极少由驱动开发者主动使用，通常是内核最底层代码在发生灾难时调用。
KERN_ALERT 1 action must be taken immediately 警报（需立即处理） 必须立刻采取行动的事件，否则会导致严重问题。例如：关键系统资源（如任务描述符、inode）耗尽，root文件系统挂载失败，或者检测到非常严重的、但可能还未导致崩溃的安全违规访问。
KERN_CRIT 2 critical conditions 严重错误 严重的错误条件，但系统可能还能继续运行一部分功能。例如：文件系统发现元数据损坏（但尝试只读挂载），硬件设备（如RK3588的PCIe控制器）报告了致命错误中断，导致该总线功能丧失。
KERN_ERR 3 error conditions （普通）错误 这是驱动开发中最常用、最重要的错误级别。 表示一个操作失败了，但系统的其他部分通常还能运行。例如：RK3588的MIPI摄像头驱动probe失败（电源、时钟、GPIO配置问题），USB设备枚举失败，DMA通道申请失败，或某个重要的内核API调用返回了错误码。 任何导致驱动或模块无法完成其核心功能的故障，都应使用KERN_ERR。
KERN_WARNING 4 warning conditions 警告 表示一些潜在的问题或非预期的、但暂时不影响功能的情况。例如：传递给驱动的某个参数超出了合理范围（驱动使用了默认值），内存分配时触发了慢路径（slow path），或检测到硬件设备处于一个非标准但支持的状态。它提示开发者“这里可能需要关注”。
KERN_NOTICE 5 normal but significant condition 通知（重要正常事件） 报告一些正常的、但具有显著意义的事件。通常用于记录系统状态的关键变化。例如：驱动模块被成功加载或卸载，RK3588的某个协处理器（如NPU）被成功初始化并上线，系统启动过程中某个重要子系统（如网络协议栈）初始化完成。
KERN_INFO 6 informational 信息性消息 输出一般的提示信息。例如：驱动在初始化时打印其版本号，探测到的硬件设备ID和名称（“Found RK3588 PCIe Endpoint device 0x1234”），或一些重要的配置信息（“Using 32-bit DMA addressing”）。这是仅次于KERN_ERR的常用级别。
KERN_DEBUG 7 debug-level messages 调试消息 专为调试阶段设计。 用于打印函数执行路径、变量值、流程状态等极其详细的细节。例如：在某个中断处理函数中打印寄存器的值，在数据流路径中打印每个数据包的头信息，或跟踪复杂的状态机切换。 切记：调试完成后，必须将此类打印删除或至少降低其等级，否则会严重污染生产环境的日志并影响性能。

实操心得一：等级选择的“黄金法则” 我的经验是，在编写驱动代码时，可以遵循一个简单法则： 问自己“如果这条信息在系统正常运行时出现，我是否需要立即知道？”

  • 需要立即知道且表明有故障 ：用 KERN_ERR 。
  • 需要知道但不算故障 ：用 KERN_NOTICE 或 KERN_INFO 。
  • 只有在深入排查这个特定模块时才需要知道 ：用 KERN_DEBUG 。
  • 不确定的，或者参数检查类 ：先用 KERN_WARNING 。 严格遵守这个法则，可以让你驱动的日志从一开始就清晰可读。

4. 掌控输出：解密 /proc/sys/kernel/printk 的四个核心参数

理解了信息如何被标记等级，下一步就是控制这些信息如何被呈现。这就是 /proc/sys/kernel/printk 这个神奇文件的职责。在终端执行 cat /proc/sys/kernel/printk ，你会看到像 4 4 1 7 这样的四个数字。它们不是随机的，而是内核日志系统的“总控开关”，每个数字都有其固定含义。

4.1 参数详解：四个数字各司其职

这四个参数按顺序分别是： console_loglevel , default_message_loglevel , minimum_console_loglevel , default_console_loglevel 。我们以 4 4 1 7 这个典型默认值来拆解：

  1. 控制台日志级别 (console_loglevel) - 第一个数字 4

    • 这是最重要的一个参数。 它定义了当前控制台的“日志过滤阈值”。
    • 规则 ：只有那些 日志等级数值小于或等于 这个阈值的消息，才会被 立即 发送到当前激活的控制台（可能是串口 ttyS0 ，也可能是图形界面的终端 tty1 等）。
    • 举例 ：当该值为 4 时，等级为 0 (EMERG) 到 4 (WARNING) 的消息会实时打印到屏幕。而等级为 5 (NOTICE)、 6 (INFO)、 7 (DEBUG) 的消息则不会在控制台显示，但它们依然被记录到了内核环形缓冲区中。
    • 作用 ：防止调试信息刷屏，确保控制台上只显示相对重要和紧急的信息。

  2. 默认消息日志级别 (default_message_loglevel) - 第二个数字 4

    • 当你在代码中调用 printk(“…”） 时，如果没有显式指定日志等级宏（如 KERN_ERR ），内核就会自动使用这个默认等级来标记这条消息。
    • 默认值是 4 ，对应 KERN_WARNING 。这就是为什么有时候你没写等级，却能看到打印的原因。
    • 最佳实践 ： 永远不要依赖这个默认值！ 每个 printk 都应该显式地指定等级宏。这是写出高质量、可维护内核代码的基本要求。

  3. 最低控制台日志级别 (minimum_console_loglevel) - 第三个数字 1

    • 这是一个安全护栏。它限制了 console_loglevel （第一个参数）可以被设置的最低值（即最高优先级）。
    • 默认是 1 ，意味着你无法通过修改第一个参数来让控制台只显示 KERN_EMERG (0) 的消息。这是为了防止用户误操作（例如设为 0 ）导致所有非紧急日志在控制台消失，从而丢失重要的错误( KERN_ERR )和警告( KERN_WARNING )信息，使得问题排查变得极其困难。

  4. 默认控制台日志级别 (default_console_loglevel) - 第四个数字 7

    • 这个值定义了内核在启动初始阶段的控制台日志级别。在启动后期，通常会被初始化脚本修改为上述第一个参数的默认值（如 4 ）。
    • 它也被用作一个参考值，例如在某些情况下重置控制台级别。

4.2 参数间的协同工作流程

我们可以用一个简单的流程图来理解当一条 printk 语句执行时，内核是如何决策的： 

printk(KERN_LEVEL “message”) 被执行
        |
        v
消息连同其 LEVEL 被放入内核环形缓冲区
        |
        v
LEVEL 数值 <= console_loglevel (第一个参数) ?
        |
    /           \
  是             否
  |               |
  v               v
立即输出到控制台    仅保存在缓冲区，
                等待 dmesg 读取

这个机制完美实现了“分级过滤，按需输出”。所有日志都被持久化记录（直到缓冲区被覆盖），但只有足够重要的日志才会打扰你的控制台。

5. 动态配置技巧：临时调整与永久设置

根据调试阶段的不同，你需要灵活调整日志级别。比如在初期排查问题时，你可能需要看到所有 DEBUG 信息；而在验证功能或生产环境，则只关心 ERROR 及以上。

5.1 临时修改（重启失效）

这是最常用的调试手段，通过直接写入 /proc/sys/kernel/printk 文件实现。

  • 查看所有日志（包括DEBUG） ：将控制台级别设为最低（数值最大），即允许所有等级输出。 

    # 将第一个参数（控制台级别）设为7
echo 7 > /proc/sys/kernel/printk
# 或者更精确地，只修改第一个参数，保持其他不变（假设原值是4 4 1 7）
echo 7 4 1 7 > /proc/sys/kernel/printk

    执行后，你的控制台会开始疯狂刷出所有 printk 信息，包括那些 KERN_DEBUG 消息。这是定位复杂流程问题的利器。

  • 只关注错误和严重问题 ：在功能稳定后，过滤掉通知、信息等“噪音”。 

    # 将控制台级别设为3，只显示0(EMERG)~3(ERR)级别的消息
echo 3 > /proc/sys/kernel/printk

    这样，控制台将变得非常安静，只有真正的错误出现时才会打印，便于你监控系统健康状况。

  • 恢复系统默认配置 ： 

    echo 4 4 1 7 > /proc/sys/kernel/printk

5.2 永久修改（需重启生效）

如果你希望某个配置在每次启动时都生效，例如在产品中固定控制台日志级别，就需要修改系统配置。

  1. 使用编辑器（如vi）打开系统配置文件 /etc/sysctl.conf ： 

    sudo vi /etc/sysctl.conf

  2. 在文件末尾添加一行配置： 

    kernel.printk = 4 4 1 7

    等号右边的四个数字就是你想永久设置的参数值，按需修改。

  3. 保存文件后，使用以下命令之一使配置立即生效（无需重启）： 

    sudo sysctl -p               # 加载 /etc/sysctl.conf 中的所有配置
sudo sysctl -w kernel.printk="4 4 1 7" # 仅修改 kernel.printk 参数

    即使不执行上一步，配置也会在下次系统重启时自动生效。

实操心得二：嵌入式环境下的配置考量 在RK3588这类嵌入式设备上，控制台常常是串口（UART），带宽有限。如果 console_loglevel 设置过高（如 7 ），大量调试日志会涌向串口，可能导致：

  1. 系统性能下降 ：打印本身消耗CPU，且可能阻塞其他任务。
  2. 关键日志丢失 ：高速刷屏时，重要的错误信息可能一闪而过，来不及看清。
  3. 增加功耗 。 因此，在产品化阶段，务必通过 /etc/sysctl.conf 将级别固定在 3 或 4 。调试时再临时调整为 7 。

6. 高效查看日志：控制台、dmesg与日志文件

获取日志的姿势也很有讲究，针对不同目的，选择最高效的工具。

6.1 实时观察控制台输出 这是最直接的方式，但受限于 console_loglevel 。你只需要在终端或串口工具中看着即可。适用于观察系统启动过程或监控已知的、高优先级的错误。

6.2 使用 dmesg 命令挖掘内核缓冲区 dmesg 是内核调试的瑞士军刀，它直接读取内核的环形缓冲区， 不受 console_loglevel 限制 ，可以查看所有级别的历史日志。

  • 查看完整日志 ： dmesg
  • 实时追踪新日志（类似 tail -f ） ： dmesg -w （注意：旧版本内核可能用 -W 或没有此选项，可用 watch dmesg 替代）
  • 按等级过滤 ： dmesg -l warn,err （只显示警告和错误级别以上的日志）
  • 按关键词搜索（最常用） ：结合 grep 
    dmesg | grep -i error      # 查找所有错误（不区分大小写）
dmesg | grep “usb”        # 查找所有USB相关日志
dmesg | grep -E “fail|error|panic” # 使用正则表达式查找失败、错误或恐慌信息
  • 查看清晰的时间戳 ： dmesg -T （将内核时间戳转换为本地可读时间，对于分析事件序列非常有用）

6.3 查阅持久化日志文件 大多数Linux发行版（如Ubuntu, Debian, CentOS）会通过 rsyslog 或 systemd-journald 等服务，将内核日志自动保存到文件中。

  • 传统syslog系统 ：日志通常位于 /var/log/kern.log 或 /var/log/messages 。 
    tail -f /var/log/kern.log      # 实时跟踪内核日志文件
grep “RK3588” /var/log/kern.log # 在历史日志中搜索特定平台关键词
  • systemd系统 ：使用 journalctl 命令，功能更强大。 
    journalctl -k                    # 查看所有内核日志
journalctl -k --since “1 hour ago” # 查看过去一小时内核日志
journalctl -k -g “i2c”          # 在所有内核日志中搜索包含“i2c”的行

注意事项：内核环形缓冲区的大小是有限的 内核日志缓冲区是一个环形队列，当它被填满后，新的日志会覆盖最旧的日志。缓冲区大小由内核编译参数 CONFIG_LOG_BUF_SHIFT 决定（例如， 17 表示 2^17 = 128KB）。在日志量巨大的调试场景下，你可能还没来得及用 dmesg 查看，关键的早期启动日志就被覆盖了。解决方法有：

  1. 尽早连接串口或终端，观察启动过程。
  2. 使用 dmesg > boot_log.txt 在启动后第一时间保存全部日志。
  3. 在内核配置中增大 CONFIG_LOG_BUF_SHIFT 的值（需要重新编译内核）。

7. 编码实战：printk的正确写法与常见陷阱

理论说再多，不如一行代码。下面我们看看在真正的内核模块或驱动中， printk 应该如何书写。

7.1 标准写法示例 

#include  // 必须包含此头文件以使用日志等级宏

// 1. 错误等级：用于报告操作失败
int ret = register_chrdev(MAJOR_NUM, “my_dev”, &fops);
if (ret < 0) {
    printk(KERN_ERR “MyDriver: Failed to register char device, error code %d\n”, ret);
    return ret;
}

// 2. 信息等级：报告正常但重要的事件
printk(KERN_INFO “MyDriver: Probing device at PCI bus %02x:%02x.%d\n”,
       pdev->bus->number, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));

// 3. 调试等级：打印详细的内部状态（调试完毕后应删除或注释）
#ifdef DEBUG
    printk(KERN_DEBUG “MyDriver: Entering interrupt handler, status reg: 0x%08x\n”,
           readl(reg_base + STATUS_OFFSET));
#endif

// 4. 警告等级：参数检查或非预期状态
if (request_size > MAX_BUFFER_SIZE) {
    printk(KERN_WARNING “MyDriver: Request size %zu too large, truncating to %d\n”,
           request_size, MAX_BUFFER_SIZE);
    request_size = MAX_BUFFER_SIZE;
}

// 5. 通知等级：模块生命周期事件
module_init(my_init);
static int __init my_init(void) {
    printk(KERN_NOTICE “MyDriver: version 1.0 loaded\n”);
    // ... 初始化代码
}
module_exit(my_exit);

7.2 必须规避的陷阱与最佳实践

  1. 陷阱一：滥用 KERN_DEBUG KERN_DEBUG 是性能杀手。它在生产环境中不仅会产生海量无用日志，更重要的是， printk 函数本身包含获取锁、格式化字符串、操作缓冲区等开销，在中断上下文或性能关键路径中频繁调用 KERN_DEBUG 会显著降低系统性能。 务必使用 #ifdef DEBUG 或类似宏将其包裹，并在发布版本中关闭DEBUG宏的定义。

  2. 陷阱二：等级使用不当

    • 该用 KERN_ERR 时用了 KERN_INFO ：一个驱动加载失败是错误( ERR )，而不是普通信息( INFO )。用错等级会导致在控制台级别设为 4 时，这个关键错误被过滤掉，让你误以为驱动加载“静默成功”了。
    • 在 printk 中忘记换行符 \n ：内核的 printk 缓冲区是行缓冲的。如果消息不以 \n 结尾，它可能不会立即刷新到日志中，导致多条打印连在一起，或者在你查看 dmesg 时最后一条消息不完整。

  3. 最佳实践：为打印信息添加前缀 在每条 printk 消息前加上一个统一的驱动或模块标识符，例如 “MyDriver: ” 。这样在查看混杂了来自内核各个子系统日志的 dmesg 时，你可以用 grep “MyDriver” 快速过滤出所有相关日志，极大提升排查效率。

  4. 最佳实践：格式化字符串检查 内核的 printk 格式化字符串与用户态 printf 略有不同。对于 %lld 、 %llu (64位整型) 等类型，为了兼容不同的架构，推荐使用内核提供的特定格式，如 %lld 和 %llu 通常是安全的，但最保险的做法是参考内核源码中的用法。避免使用不安全的 %n 格式符。

8. 高级调试技巧与问题排查实录

当你熟悉了基础操作，下面这些进阶技巧和常见问题排查经验，能让你在复杂的内核调试中更加游刃有余。

8.1 动态调整特定模块的日志级别 有时你只想看某个特定驱动或子系统的 DEBUG 日志，而不想被其他模块的日志干扰。这可以通过 /sys/module/<module_name>/parameters/ 下的参数来实现（如果该模块设计了这样的参数）。更通用的方法是利用 pr_debug 和动态调试（Dynamic Debug）。

pr_debug() 是一个比 printk(KERN_DEBUG) 更先进的宏。当 CONFIG_DYNAMIC_DEBUG 内核选项被启用时，你可以在系统运行时，动态地开启或关闭特定文件、函数甚至行号的 pr_debug() 输出。 

# 启用某个文件中的所有 pr_debug 信息
echo “file drivers/usb/gadget/udc.c +p” > /sys/kernel/debug/dynamic_debug/control

# 启用某个函数中的所有 pr_debug
echo “func usb_gadget_probe_driver +p” > /sys/kernel/debug/dynamic_debug/control

# 禁用所有 pr_debug
echo “-p” > /sys/kernel/debug/dynamic_debug/control

这需要内核编译时开启 CONFIG_DYNAMIC_DEBUG ，并在代码中使用 pr_debug() 而非 printk(KERN_DEBUG) 。

8.2 常见问题排查速查表

问题现象 可能原因 排查步骤与解决方案
控制台没有任何printk输出 1. 控制台日志级别设置过高。
2. 控制台设备未正确初始化或选择错误。
3. 内核启动参数 quiet 或 loglevel=0 。 		1. 执行 cat /proc/sys/kernel/printk 检查第一个值，临时设为 7 。
2. 检查内核命令行参数 console= 是否正确指定了串口设备（如 console=ttyS0,115200 ）。
3. 检查 dmesg 是否有输出。如果有，则问题在于控制台路径。
dmesg命令显示空白或“权限被拒绝” 1. 缓冲区确实为空（刚启动）。
2. 需要root权限。 		1. 尝试触发一些内核事件（如插入USB设备）。
2. 使用 sudo dmesg 。
早期启动日志（如PCI探测、驱动初始化）丢失 内核环形缓冲区被后续日志覆盖。 1. 增大内核配置 CONFIG_LOG_BUF_SHIFT 。
2. 通过串口在启动最早阶段抓取日志。
3. 使用 dmesg -s 131072 （指定更大缓冲区）或直接 dmesg > /tmp/full_dmesg.log 在启动后第一时间保存。
printk打印导致系统变慢或卡死 1. 在中断上下文或原子上下文中执行了耗时长的printk。
2. 启用了 KERN_DEBUG 导致打印风暴。
3. 控制台（如慢速串口）成为瓶颈。 		1. 检查printk调用上下文，避免在中断处理函数中打印过多内容。
2. 关闭或减少 KERN_DEBUG 打印。
3. 提高串口波特率，或临时将日志级别调高，减少控制台输出量。
日志时间戳混乱或不准确 1. 系统时间未同步。
2. 使用的是相对时间戳。 		1. 使用 dmesg -T 查看本地时间（需要系统时间正确）。
2. 理解 dmesg 默认输出的是从内核启动开始的秒数。

8.3 在RK3588平台上的特殊考量 调试RK3588这类多核异构SoC时，日志可能来自多个CPU核心或协处理器（如DSP、NPU）。

  • 核间同步 ：多个核心同时调用 printk 是安全的，内核内部有锁机制保护，但这可能引入性能抖动。在极端性能调优时需注意。
  • 早期调试 ：在RK3588的Bootloader（如U-Boot）到内核早期启动阶段，串口驱动可能还未完全初始化。此时可能需要依赖U-Boot的 printch 等更底层的输出，或者使用JTAG等硬件调试工具来捕捉最早期的日志。
  • 驱动标识 ：在编写RK3588各个子系统（如VOP显示、NPU、ISP）的驱动时，强烈建议在 printk 前缀中使用明确的子模块名，例如 “RK3588-VOP: ” 、 “RK3588-NPU: ” ，这样在复杂的系统日志中能快速定位。

掌握 printk 的日志等级机制，本质上是在掌握一种与Linux内核高效对话的方法。它让你从被动的日志接收者，变成了主动的日志管理者。从理解八个等级的含义开始，到熟练操控四个核心参数，再到在代码中规范、克制地使用它，最后能利用各种工具高效地检索和分析日志——这个过程，正是从一个内核开发新手向老手进阶的标志。下次当你面对RK3588内核那看似杂乱无章的启动信息时，希望你能想起这篇文章里的技巧，从容地打开过滤器，精准地捕获到你想要的那条关键错误日志。

Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

【Linux-System-35】【Linux信号机制全链路解析】流食般投喂

avatar openEuler 社区
cover

国产芯片、操作系统、AI框架与互联技术，系统梳理2026年我国自主可控计算基础设施的建设现状、技术突破与生态进展

avatar openEuler 社区

一文搞懂：OS堆/栈 和 JVM堆/栈的本质区别与包含关系

OS的堆、栈：操作系统原生内存模型，面向C/C++原生代码；栈线程私有，堆进程共享；JVM的堆、虚拟机栈：JVM在OS用户内存之上自建的逻辑内存模型，面向Java字节码；Java线程对应OS线程，同时存在JVM虚拟机栈 + OS原生栈两套栈结构；JVM堆底层依赖OS虚拟内存，但内存管理器是GC；JVM内部C代码才会使用malloc的OS堆；元空间属于本地内存，不属于JVM堆，不受-Xmx限制。

avatar openEuler 社区