1. 项目概述与核心动机

最近在搞一个Linux内核模块的性能优化，遇到了一个老生常谈但又极其棘手的问题：内存管理。具体来说，是在一个高频调用的路径上，需要动态分配和释放一个复杂的结构体。传统的 kmalloc / kfree 组合虽然直接，但在复杂的错误处理和多出口函数中，稍有不慎就会导致内存泄漏或者重复释放，调试起来简直是噩梦。尤其是在内核开发中，没有用户空间那么完善的调试工具，一个隐蔽的泄漏可能运行几天甚至几周才会暴露，定位成本极高。

这让我开始思考，能否将用户空间C++中成熟的RAII（资源获取即初始化）思想引入内核模块？核心目标就是用对象生命周期来绑定资源生命周期，确保资源在任何情况下（包括异常退出）都能被正确释放。C++标准库中的 std::unique_ptr 正是这一思想的典范，而 std::make_unique 则进一步简化了创建过程。虽然内核是C的天下，但C++作为“更好的C”，其核心库的某些思想完全可以被借鉴和适配。这个项目，就是尝试在内核模块的特定场景下，模拟 std::unique_ptr 和 std::make_unique 的行为，来管理通过 kmalloc 分配的内核结构体内存，从而提升代码的健壮性和可维护性。

简单来说，这不是要在内核里编译C++代码，而是用纯C实现一套类似智能指针的机制，专门用于管理内核中通过 kmalloc 分配的、生命周期明确的单个结构体对象。它适合所有正在或即将进行Linux内核模块开发，并对代码质量和内存安全有较高要求的开发者。即使你主要用C，理解这种资源管理范式也能极大改善你的代码设计。

2. 核心思路与方案设计

2.1 从用户空间 std::unique_ptr 汲取灵感

std::unique_ptr 的精髓在于“独占所有权”和“自动释放”。一个 unique_ptr 对象拥有其指向对象的所有权，当这个 unique_ptr 对象被销毁（例如离开作用域）时，它会自动调用删除器来释放其拥有的资源。这完美契合了我们内核模块中“分配-使用-释放”的单次生命周期场景。

我们需要在内核中模拟的关键特性有：

  1. 类型安全 ：包装特定类型的指针，避免误用。
  2. 移动语义 ：所有权可以转移，但不能复制，防止多个指针管理同一块内存。
  3. 自定义删除器 ：因为内核内存使用 kfree 释放，而非 delete 。
  4. 便捷的创建接口 ：类似 std::make_unique ，能够一次性完成内存分配和对象构造（初始化）。

2.2 内核适配方案选型

直接在内核中使用C++编译器是不现实且不被社区接受的。因此，我们的方案是 用C语言结构和函数来模拟 。

为什么不直接用 kfree 在函数末尾释放？ 在简单的线性函数中确实可以。但考虑以下场景： 

int complex_operation(struct device *dev) {
    struct my_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
    if (!data) return -ENOMEM;

    // 初始化 data 的部分成员
    data->dev = dev;

    // 操作1
    int ret = op1(data);
    if (ret) {
        kfree(data); // 记得释放
        return ret;
    }

    // 操作2
    ret = op2(data);
    if (ret) {
        kfree(data); // 又得释放
        return ret;
    }

    // ... 更多操作和出口
    kfree(data); // 正常出口也要释放
    return 0;
}

每个错误出口都需要手动调用 kfree ，极易遗漏。而使用我们的“智能指针”，只需要在函数开头“获取”资源，无论函数从哪个出口返回，资源都会自动释放。

方案核心设计： 我们将定义一个结构体 kernel_unique_ptr ，它内部包含：

  • 一个指向托管对象的泛型指针 void* ptr 。
  • 一个函数指针 deleter ，指向具体的释放函数（如 kfree 的包装）。
  • 利用GCC的 cleanup 属性，这是一个编译器扩展，允许指定一个变量离开作用域时自动执行的清理函数。

2.3 cleanup 属性：实现自动释放的关键

GCC的 __attribute__((cleanup)) 是此方案能成立的基础。它允许你为一个自动变量（栈变量）注册一个清理函数，当这个变量离开其作用域时，无论是通过 return 、 goto 还是异常（在内核中较少），清理函数都会被调用。

基本用法示例： 

void auto_kfree(void **ptr) {
    if (ptr && *ptr) {
        printk(KERN_DEBUG "Auto freeing memory at %p\n", *ptr);
        kfree(*ptr);
        *ptr = NULL;
    }
}

void example_function(void) {
    // 用 cleanup 属性声明指针，指定清理函数
    void *buffer __attribute__((cleanup(auto_kfree))) = NULL;
    buffer = kmalloc(1024, GFP_KERNEL);
    if (!buffer) return; // 即使这里返回，auto_kfree也会被调用（buffer为NULL，kfree安全）
    // 使用 buffer...
    // 函数结束时，auto_kfree(buffer) 自动调用，释放内存。
}

这实现了最基本的RAII。我们的 kernel_unique_ptr 就是将这个机制进行类型封装和功能强化。

3. 核心实现细节解析

3.1 定义 kernel_unique_ptr 结构体与删除器

首先，我们需要定义核心的数据结构和操作接口。 

// kernel_unique_ptr.h
#ifndef _KERNEL_UNIQUE_PTR_H
#define _KERNEL_UNIQUE_PTR_H

#include <linux/slab.h> // 为了 kmalloc/kfree
#include <linux/types.h>

// 前向声明，删除器函数类型
typedef void (*kernel_deleter_t)(void *);

// 核心的“智能指针”结构体
typedef struct kernel_unique_ptr {
    void *ptr;                  // 托管的内核对象指针
    kernel_deleter_t deleter;   // 对应的删除器函数
} kernel_unique_ptr_t;

// 一个通用的、使用 kfree 的删除器
static inline void kernel_default_deleter(void *p) {
    if (p) {
        kfree(p);
    }
}

// 核心的清理函数，供 `cleanup` 属性调用
static inline void kernel_unique_ptr_cleanup(kernel_unique_ptr_t *kuptr) {
    if (kuptr && kuptr->deleter && kuptr->ptr) {
        kuptr->deleter(kuptr->ptr);
        kuptr->ptr = NULL; // 避免悬空指针
        kuptr->deleter = NULL;
    }
}

// 类似 std::make_unique 的创建函数
// 使用 _Generic 进行类型推导（C11），简化调用。如果编译器不支持，需要定义多个类型特化版本。
#define kernel_make_unique(type, deleter) \
    __kernel_make_unique_impl(sizeof(type), deleter, __alignof__(type))

// 内部实现函数
static inline kernel_unique_ptr_t __kernel_make_unique_impl(size_t size,
                                                             kernel_deleter_t deleter,
                                                             size_t alignment) {
    kernel_unique_ptr_t kuptr = {
        .ptr = kmalloc(size, GFP_KERNEL),
        .deleter = deleter,
    };
    // 如果分配失败，ptr为NULL，清理函数会安全地处理（deleter(NULL)是安全的）
    if (kuptr.ptr) {
        // 可选：将新分配的内存清零，类似 calloc。根据需求决定。
        memset(kuptr.ptr, 0, size);
    }
    return kuptr;
}

// 获取原始指针的辅助宏，保持类型安全
#define kernel_unique_ptr_get(kuptr, type) ((type *)((kuptr).ptr))

// 释放所有权，返回原始指针并清空智能指针
#define kernel_unique_ptr_release(kuptr) \
    ({ \
        void *__tmp = (kuptr).ptr; \
        (kuptr).ptr = NULL; \
        (kuptr).deleter = NULL; \
        __tmp; \
    })

#endif // _KERNEL_UNIQUE_PTR_H

关键点解析：

  1. 结构体设计 ： kernel_unique_ptr_t 简单明了，只包含资源指针和释放方法。它本身是一个小的栈对象，开销极小。
  2. 删除器 ： kernel_default_deleter 是对 kfree 的简单包装。这个设计是开放的，未来可以轻松扩展用于释放其他资源（如 vmalloc 、 dma_alloc_coherent 分配的内存，或者需要调用特定析构函数的结构体）。
  3. 清理函数 ： kernel_unique_ptr_cleanup 是RAII的发动机。它检查所有条件后调用删除器。将 ptr 置为 NULL 是一个好习惯，可以防止清理函数被误调用多次。
  4. kernel_make_unique 宏 ：这是用户体验的关键。它试图模仿 std::make_unique<T>() 。我们利用C11的 _Generic 或者通过后续的“类型特化”宏来让调用者无需显式写出类型大小。这里展示的宏是一个简化版，它需要调用者传递类型和删除器。更完善的版本见下文。
  5. release 操作 ：有时我们需要将内存的所有权转移出智能指针的管理范围（例如，将其传递给一个承诺会负责释放的旧式API）。 kernel_unique_ptr_release 宏实现了这个功能，它返回原始指针并将智能指针置空。

3.2 实现类型安全的 KERNEL_MAKE_UNIQUE

为了让调用像 std::make_unique<MyStruct>() 一样自然，我们需要根据传入的结构体类型自动推导大小和删除器。由于内核代码可能使用不同标准的C编译器，我们提供两种方案。

方案一：使用C11 _Generic （如果编译器支持） 

// 为每种我们关心的类型定义一个删除器（通常都用默认的即可）
#define _KERNEL_DELETER_OF(type) kernel_default_deleter

// 主创建宏
#define KERNEL_MAKE_UNIQUE(type) \
    (kernel_unique_ptr_t) { \
        .ptr = kmalloc(sizeof(type), GFP_KERNEL), \
        .deleter = _KERNEL_DELETER_OF(type), \
    } __attribute__((cleanup(kernel_unique_ptr_cleanup)))

注意：这里将 cleanup 属性直接放在了复合字面量上，这是一种技巧。但更常见的做法是将宏展开为一个变量声明。

方案二：更兼容的“类型特化”宏（推荐） 由于内核代码对C版本要求不一，定义一个针对特定类型的宏更为稳妥。 

// 为 `struct my_data` 特化的创建宏
#define KERNEL_MAKE_UNIQUE_MY_DATA() \
    ({ \
        kernel_unique_ptr_t __kuptr __attribute__((cleanup(kernel_unique_ptr_cleanup))) = \
            kernel_make_unique(struct my_data, kernel_default_deleter); \
        __kuptr; \
    })

这个宏展开后，会创建一个名为 __kuptr 的、带有 cleanup 属性的栈变量，并立即初始化它。整个表达式的结果就是这个智能指针对象。调用方式为 kernel_unique_ptr_t data_ptr = KERNEL_MAKE_UNIQUE_MY_DATA(); 。

虽然需要为每个类型定义一个宏，但一旦定义，使用起来非常直观和安全。我们可以用另一个宏来简化这个定义过程： 

// 辅助宏，用于定义针对特定类型的 make_unique 宏
#define DEFINE_KERNEL_MAKE_UNIQUE(type, func_name) \
    static inline kernel_unique_ptr_t func_name(void) { \
        kernel_unique_ptr_t __kuptr __attribute__((cleanup(kernel_unique_ptr_cleanup))) = \
            kernel_make_unique(type, kernel_default_deleter); \
        return __kuptr; \
    }

// 使用：在头文件或C文件中定义
DEFINE_KERNEL_MAKE_UNIQUE(struct my_data, make_unique_my_data)
// 然后就可以调用：kernel_unique_ptr_t ptr = make_unique_my_data();

3.3 完整的使用示例

假设我们有一个内核结构体 struct sensor_reading 。 

// sensor_driver.c
#include "kernel_unique_ptr.h"

struct sensor_reading {
    u64 timestamp;
    s32 temperature;
    s32 humidity;
    struct list_head node;
};

// 使用辅助宏定义该类型的创建函数（只需一次）
DEFINE_KERNEL_MAKE_UNIQUE(struct sensor_reading, make_unique_sensor_reading)

static int process_sensor_data(void) {
    int ret = 0;

    // 1. 创建智能指针。内存分配和清理绑定到`reading_ptr`的生命周期。
    kernel_unique_ptr_t reading_ptr = make_unique_sensor_reading();
    struct sensor_reading *reading = kernel_unique_ptr_get(reading_ptr, struct sensor_reading);

    // 检查分配是否成功
    if (!reading) {
        printk(KERN_ERR "Failed to allocate sensor reading\n");
        return -ENOMEM; // 返回时，reading_ptr的cleanup属性会安全调用清理函数（ptr为NULL，无事发生）
    }

    // 2. 使用托管的对象
    reading->timestamp = ktime_get_ns();
    reading->temperature = read_temperature_from_hw();
    if (reading->temperature < -1000) { // 假设的硬件错误
        ret = -EIO;
        goto out; // 跳转到out标签，reading_ptr会自动释放内存！
    }
    reading->humidity = read_humidity_from_hw();
    INIT_LIST_HEAD(&reading->node);

    // 3. 可能的所有权转移场景
    // 假设有一个全局链表，其维护者会负责释放
    spin_lock(&global_list_lock);
    list_add_tail(&reading->node, &global_sensor_list);
    spin_unlock(&global_list_lock);
    // 此时，所有权已转移给全局链表。我们必须让智能指针放弃所有权，避免双重释放。
    kernel_unique_ptr_release(reading_ptr); // reading_ptr.ptr 现在为NULL

    // 4. 正常返回
    ret = 0;
    goto out;

out:
    // 注意：这里不需要手动 kfree！
    // 如果之前调用了 `release`，reading_ptr.ptr 为 NULL，清理函数不会做任何事情。
    // 如果因为错误跳转到这里，reading_ptr.ptr 非空，清理函数会正确释放内存。
    // 函数结束，`reading_ptr` 离开作用域，清理函数被自动调用（作为最后的安全网）。
    return ret;
}

4. 深入剖析：优势、局限与最佳实践

4.1 与传统模式对比的优势

  1. 强化的异常安全性 ：这是最大优点。无论函数有多少个错误返回点，甚至是使用 goto 进行集中清理，资源释放逻辑只有一处（在清理函数中），完全避免了遗漏。
  2. 代码简洁性 ：释放资源的代码不再散落在各个 return 语句之前，函数主体逻辑更清晰，专注于业务操作。
  3. 可维护性 ：如果未来释放资源的方式需要改变（例如从 kfree 改为专用的缓存释放器），只需要修改删除器函数或 kernel_make_unique 的实现，所有使用该智能指针的代码自动生效。
  4. 明确的资源所有权语义 ：变量名 reading_ptr 本身就是一个文档，清晰地表明“这个指针拥有其所指对象的所有权”。这比一个裸指针 struct sensor_reading *reading 传达了更多信息。

4.2 存在的局限与注意事项

  1. 仅限自动存储期（栈变量） ： cleanup 属性只对自动变量有效。这意味着你不能将 kernel_unique_ptr_t 用于全局变量、静态变量或堆分配的结构体成员。这是此方案最主要的限制。它最适合管理函数内部的、生命周期与函数作用域一致的资源。
  2. 编译器依赖 ： __attribute__((cleanup)) 是GCC/Clang扩展，并非标准C。虽然Linux内核严重依赖GCC，这在实际中不是问题，但如果你需要编写高度可移植的、不依赖特定编译器的代码，则不能使用此方案。
  3. 对数组支持不友好 ： std::unique_ptr 有对数组的特化（ std::unique_ptr<T[]> ）。我们的简易实现没有区分数组和单个对象，删除器默认使用 kfree ，这对于 kmalloc 分配的数组来说是正确的，但缺少了数组访问的边界安全和 operator[] 这样的语法糖。如果需要，可以定义 KERNEL_MAKE_UNIQUE_ARRAY 宏。
  4. 调试复杂性略有增加 ：当发生内存错误时，问题可能出现在智能指针的清理逻辑中，而不是你显式写的 kfree 处。需要熟悉这套机制才能快速定位。
  5. 性能开销 ：理论上，相比手动调用 kfree ，此方案有极小的额外开销：一个额外的函数指针存储，以及函数退出时对清理函数的间接调用。但在绝大多数场景下，这点开销可以忽略不计。关键在于，它用微小的运行时开销换来了巨大的开发时安全和代码维护性的提升。

4.3 内核开发中的最佳实践建议

  1. 划定适用范围 ：明确这套机制最适合管理在函数内部创建、并在同一函数或其后代作用域内销毁的“局部资源”。对于需要跨函数传递、生命周期更复杂的对象，应考虑其他所有权模型（如引用计数 kref ）。
  2. 结合 kref 使用 ：对于需要共享所有权的内核对象，Linux内核提供了标准的 kref 引用计数机制。你可以设计一个删除器，当 kernel_unique_ptr 释放所有权时，它调用 kref_put 。这样，智能指针管理着最初的引用，当需要共享时，通过 kref_get 增加引用，最后通过 kref_put 统一释放。 
    struct my_object {
    struct kref refcount;
    // ... other data
};

void object_release(struct kref *kref) {
    struct my_object *obj = container_of(kref, struct my_object, refcount);
    kfree(obj);
}

static inline void kernel_deleter_for_kref(void *p) {
    struct my_object *obj = p;
    if (obj) {
        kref_put(&obj->refcount, object_release);
    }
}
// 创建时使用 kernel_deleter_for_kref 作为删除器
  3. 为复杂结构体定义专用删除器 ：如果结构体内部还包含其他需要释放的资源（如嵌套分配的指针、已获取的锁、打开的文件描述符等），应该为其编写专用的删除器函数，在释放结构体本身之前，先妥善清理这些子资源。
  4. 清晰的命名约定 ：给返回智能指针的创建函数起一个清晰的名字，如 make_unique_xxx 。变量名也可以加后缀 _ptr 或 _owner 以示区分。
  5. 在头文件中集中声明 ：将常用的 DEFINE_KERNEL_MAKE_UNIQUE 定义放在公共头文件或模块专用的头文件中，确保一致性。

5. 扩展：模拟 std::shared_ptr 的可能性探讨

std::unique_ptr 对应的是独占所有权。在内核中，共享所有权更为常见，通常由 kref 实现。我们能否用类似的方法包装 kref ，模拟 std::shared_ptr 呢？

思路是创建一个 kernel_shared_ptr_t 结构体，它内部包含一个指向目标对象的指针和一个指向 kref 的指针（或者将 kref 嵌入到对象中， shared_ptr 持有对象指针）。清理函数调用 kref_put 。 

typedef struct kernel_shared_ptr {
    void *ptr;
    struct kref *ref; // 假设 ref 在托管对象内部
} kernel_shared_ptr_t;

static inline void kernel_shared_ptr_cleanup(kernel_shared_ptr_t *ksptr) {
    if (ksptr && ksptr->ptr && ksptr->ref) {
        kref_put(ksptr->ref, obj_release_func);
        ksptr->ptr = NULL;
        ksptr->ref = NULL;
    }
}

创建函数需要分配对象并初始化其内部的 kref 。拷贝一个 kernel_shared_ptr 需要调用 kref_get 。

然而，这种实现的复杂性远高于 unique_ptr ，因为需要管理 kref 的初始化和获取/释放的配对。而内核的 kref 本身就已经是一个设计良好的共享所有权机制。因此，在实践中，直接使用 kref 可能比包装一层“智能指针”接口更简单、更符合内核习惯。 kernel_unique_ptr 的价值在于它为没有内置引用计数的、生命周期简单的对象提供了自动化管理，填补了 kref 之外的空白。

6. 常见问题与调试技巧

6.1 问题排查清单

问题现象 可能原因 排查步骤与解决方案
编译错误： warning: ‘cleanup’ attribute ignored 1. 变量不是自动变量（如 static、全局）。
2. 变量类型是数组（某些版本GCC对数组支持不佳）。 		1. 确保 kernel_unique_ptr_t 变量在函数内部声明，无 static 修饰。
2. 尝试将数组改为指针，或查阅对应GCC版本文档。
内核Oops或内存泄漏 1. 在调用 release() 后，又试图通过智能指针访问 ptr 。
2. 删除器函数实现有误（如双重释放）。
3. 托管的对象内部有需要手动释放的资源，但删除器未处理。 		1. release() 后，应将智能指针视为空状态，不再使用。可以在删除器中加入调试打印。
2. 确保删除器检查 ptr 非空后再释放，并将 ptr 置NULL。
3. 编写专用的、完整的删除器，释放所有子资源。
分配失败时程序行为异常 分配失败时， kmalloc 返回 NULL ，智能指针内部的 ptr 为 NULL 。 1. 使用 kernel_unique_ptr_get 宏获取原始指针后， 必须 检查是否为 NULL 。
2. 这是良好的编程习惯，与使用裸指针时无异。
性能热点分析显示清理函数耗时 在极高频、性能极其敏感的路径（如网络数据包处理的核心循环）中使用。 1. 评估是否真的需要在此路径动态分配。考虑使用预分配池（slab缓存、mempool）。
2. 如果必须使用，衡量其实际开销。通常，单次函数指针调用和条件判断的开销可以接受。

6.2 调试与日志技巧

为了便于调试，可以在删除器和清理函数中加入详细的日志。 

static inline void kernel_default_deleter_debug(void *p) {
    if (p) {
        printk(KERN_DEBUG "%s: Freeing memory at %p (called from %pS)\n",
               __func__, p, __builtin_return_address(0));
        kfree(p);
    }
}

使用 __builtin_return_address(0) 可以获取调用删除器的函数地址，配合 %pS 打印格式，可以在内核日志中看到符号名，对于追踪释放位置非常有帮助。

一个重要的提醒 ：在最终的生产代码中，应移除这些调试打印，或将其置于 #ifdef DEBUG 宏之下，以避免日志风暴。

6.3 与内核其他机制的协同

  • Slab缓存 ：如果管理的是频繁创建销毁的同类型小对象，使用 kmem_cache 效率更高。你可以轻松地修改删除器，将 kfree 替换为 kmem_cache_free 。 
    struct kmem_cache *my_cache;
void my_cache_deleter(void *p) {
    if (p) kmem_cache_free(my_cache, p);
}
// 创建时指定删除器
kernel_unique_ptr_t ptr = { .ptr = kmem_cache_alloc(my_cache, GFP_KERNEL),
                            .deleter = my_cache_deleter };
  • DMA内存 ：对于通过 dma_alloc_coherent 分配的内存，删除器应使用 dma_free_coherent 。
  • 资源获取函数 ：此模式不仅限于内存。可以用于管理任何需要配对操作的资源，如 mutex_lock / mutex_unlock 、 get_device / put_device 、 clk_prepare_enable / clk_disable_unprepare 。只需定义对应的“获取”函数和“删除器”（即释放函数）。

7. 总结与个人体会

这套基于 cleanup 属性的“内核智能指针”机制，是我在经历了多次内存泄漏调试痛苦后，借鉴用户空间现代C++实践的一次成功探索。它并没有引入什么高深莫测的黑科技，而是巧妙地利用了一个已有的编译器特性，将资源管理的责任从容易出错的人脑转移给了严谨的编译器。

在实际项目中引入它之后，最直观的感受是，函数中关于错误处理的代码变得干净了许多。以前写一个函数，总要战战兢兢地数着有几个 goto 标签，每个标签前是否都释放了该释放的资源。现在，只需要在函数开头“声明所有权”，然后就可以专注于业务逻辑，释放的事情交给“命运”（作用域结束）。代码的可读性和可维护性得到了实实在在的提升。

当然，它不是一个银弹。正如前面分析的，它受限于栈变量和特定的编译器。对于复杂的、生命周期跨越多个函数或模块的对象， kref 仍然是内核的标准答案。但对于大量存在的、函数内局部使用的动态分配对象，这个轻量级的包装器提供了一个非常优雅的解决方案。

最后，我想分享一个具体的编码习惯：当我决定使用这个模式时，我会立刻为我要管理的结构体类型，通过 DEFINE_KERNEL_MAKE_UNIQUE 宏定义好创建函数。这个动作本身就像是一种设计宣言，提醒我和其他阅读代码的人：“这个资源的所有权是明确的、局部的，并且会被自动管理。” 这种清晰的意图表达，其价值有时甚至超过了自动释放本身。

Logo
openEuler 社区

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

更多推荐

cover

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

avatar openEuler 社区

银河麒麟高级服务器操作系统日志采集标准处理流程

本文档提供银河麒麟高级服务器操作系统标准化日志采集流程，便于统一技术支持标准、缩短问题定位周期，且确保采集的信息完整、准确、可直接用于根因分析。本文档适用于技术支持工程师及具备操作系统操作权限的技术人员，覆盖银河麒麟高级服务器操作系统，适用阶段为服务器故障排查、问题复现、根因分析阶段的日志采集工作。执行1次，快速定位负载类型# 系统整体负载与CPU占用# 内存与虚拟内存状态# 进程维度信息（按CP

avatar openEuler 社区

鸿蒙操作系统使用 relationalStore 实现本地 RDB 数据库增删改查实战

本文用完成了鸿蒙应用本地数据库从建库建表到增删改查、事务批量写入的完整实现，核心代码约 150 行，全部可直接编译运行。掌握 RDB Store 后，应用内的列表缓存、离线数据、结构化配置都有了一个可靠且可扩展的落地方案。

avatar openEuler 社区