- 博客(1272)
- 资源 (4)
- 问答 (1)
- 收藏
- 关注
RSS订阅
原创 Linux系统软件工程师/嵌入式Linux应用开发工程师 知识体系构建 500篇（持续更新）
今年受疫情影响，企业经营必不可免地受到冲击，企业在选人用人方面比以往都更加谨慎，招聘也更加苛刻。hr都试图用最低的成本去招最优秀的人才。本人从事嵌入式软件开发多年，结合自己的经验，推出了《嵌入式软件工程师技术面专题》，预计会有40篇，分成硬件协议、多进程多线程编程、网络编程、linux基础、C/C++等几大模块，每一篇在末尾都总结了相关提问，其中有些知识，即使是工作了两三年的同学也未必都懂，所以社招的同学也可以看，对于找工作绝对有帮助。**不打无准备之战，提前做好准备，方可立于不败之地**。欢迎大家订阅，只
2020-09-13 11:12:01
51493
73
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(3) 守护进程
守护进程(daemon)，是一种运行在后台 的特殊进程，它独立于控制终端 ，并周期性地执行某项任务或等待处理某些发生的事件。守护进程是个特殊的孤儿进程，这种进程脱离终端，为什么要脱离终端呢？之所以脱离于终端是为了避免进程被任何终端所产生的信息所打断，其在执行过程中的信息也不在任何终端上显示。由于在 Linux 中，每一个系统与用户进行交流的界面称为终端，每一个从此终端开始运行的进程都会依附于这个终端，这个终端就称为这些进程的控制终端，当控制终端被关闭时，相应的进程都会自动关闭。但是守护进程却能突破这种限制
2020-08-17 09:21:18
4048
4
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(4) 进程同步和通信的方式有哪些？
🥇 作者简介： 热衷于知识探索和分享的技术博主。💂 csdn主页:：【✍️ 微信公众号：【🎉精彩专栏：🎓 【 🧡 【 📚【 🌎【✍️ 【 …💂关于作者: 曾就职于国内知名安防上市公司，现就职于国内知名AMR机器人公司，担任高级系统软件工程师。2020年至今保持CSDN博客专家，CSDN C/C++领域优质创作者头衔。全网5万+粉丝。十载寒冰，难凉热血；多年过去，历经变迁，物是人非。然而，对于技术的探索和追求从未停歇。💪坚持创作，热衷分享，初心未改，继往开来！
2020-08-16 16:27:48
11462
2
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(15) 内核空间、用户空间、内核态、用户态
为了保证用户进程不能直接操作内核，保证内核安全，操作系统将虚拟空间划分为两部分，一部分是内核空间，一部分是用户空间。针对Linux操作系统，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF）供内核使用，称为内核空间，而较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。对于校招而言，该问题提问几率较大，因为是基础性问题，考察对内核空间和用户空间的理解，进程的内核态和用户态等概念。），进程切换时，用户空间切换，内核空间不变。
2020-08-16 16:18:39
15515
2
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(13) 请你描述下进程虚拟内存空间布局
对于这个问题，面试官可能拿出一张白纸，让你尝试画出linux下进程的虚拟内存空间布局，然后=再让你简述下每个分区的作用，可能会挑几个重点分区，例如堆区、栈区来进行深入展开，考察你对堆栈的理解等等。文章目录1 内核空间2 栈(stack)3 内存映射段(mmap)4 堆(heap)5 BSS段6 数据段(Data)7 代码段(text)8 保留区问题提问在多任务操作系统中，每个进程都运行在属于自己的内存沙盘中。这个沙盘就是虚拟地址空间(Virtual Address Space)，在32位模式下它是一个4
2020-08-16 16:00:34
2503
2
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(1) 进程和线程的基本概念与区别
进程（Process）是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。程序是指令、数据及其组织形式的描述，进程是程序的实体。线程（thread）是操作系统能够进行调度的最小单位。它被包含在进程之中，一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。
2020-08-15 12:59:17
3757
2
原创 Linux C/C++ or 嵌入式面试之《网络编程系列》(4) tcp四次断开若干问题
首先A向B发送一个FIN报文段，报文段首部FIN=1，序列号seq=u（u为最后传送的数据的序列号加1，因为tcp规定，fin包消耗一个序列号，虽然没有发送数据），然后A进入FIN-WAIT-1（终止等待1）状态。（2）B收到释放连接的报文段后即发出确认报文段，报文首部ACK=1，ack=u+1，seq=v（v等于B前面传送过的数据的序列号加1），然后B进入CLOSE-WAIT（关闭等待）状态。（3）当A收到B的确认报文后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
2020-08-15 12:52:33
15100
2
原创 fastdds源码分析之数据分发流程
✅EntityID 索引：使用哈希表按 EntityID 快速查找匹配的 Reader✅预注册机制：DataReader 创建时注册到 MessageReceiver✅一对多分发：支持一个 EntityID 对应多个 Reader✅回调分发：通过函数回调遍历处理所有匹配的 Reader✅安全检查：支持安全模式下的加密/解密检查✅零拷贝优化：DataSharing 模式避免内存拷贝。
2026-04-28 10:00:30
16
原创 fastdds源码分析之EDP协议
EDP是 RTPS 协议中用于发现端点（Writer/Reader）的协议，是 DDS 发现机制的核心部分。│ EDP 总结 ││ ││ 职责: 发现同 Participant 内所有的 Writer 和 Reader ││ ││ 使用内置主题: ││ • DCPSPublication - 发布者信息 ││ • DCPSSubscription - 订阅者信息 ││ ││ 依赖: PDP (先发现 Participant) ││ ││ 匹配条件: ││ • Topic 名称相同 │。
2026-04-26 22:40:43
44
原创 fastdds源码分析之PDP协议
PDP是 RTPS 协议中用于发现参与者 (Participant)的协议，是 DDS 发现机制的第一步。│ PDP 总结 ││ ││ 职责: 发现同一 Domain 内的所有 Participant ││ ││ 实现: SPDP (Simple Participant Discovery Protocol) ││ ││ 内置端点: ││ • SPDP Writer - 广播本地 Participant 信息 ││ • SPDP Reader - 接收远程 Participant 信息 │。
2026-04-26 22:38:14
37
原创 fastdds源码分析之WriterListener
WriterListener 是 RTPS Writer 的事件回调接口，用户可以重写这些虚方法来接收 Writer 相关的通知事件。│ WriterListener 回调总结 ││ ││ 事件类型: ││ • on_writer_matched - 匹配事件 ││ • on_offered_incompatible_qos - QoS 不兼容 ││ • on_writer_change_received_by_all - 数据被所有人接收 │。
2026-04-26 22:25:59
56
原创 fastdds源码分析之Locator
│ Locator 总结 ││ ││ 本质: 网络地址 + 端口的抽象 ││ ││ 作用: ││ • 定位目标 (UDP/TCP/SHM) ││ • 统一不同传输协议的地址表示 ││ • 用于发送和接收数据 ││ ││ 特点: ││ • 支持 IPv4/IPv6/SHM/Ethernet ││ • kind 区分传输类型 ││ • 16 字节地址支持 IPv6 ││ │。
2026-04-26 21:58:41
50
原创 fastdds源码分析之可靠传输机制分析
│ 可靠传输机制总结 ││ ││ 核心机制: ││ 1. 周期性发送 Heartbeat (100ms) ││ 2. Reader 收到 Heartbeat 后，比较自己历史，发 AckNack ││ 3. Writer 收到 AckNack 后，重传缺失数据 ││ 4. 如果一些数据被 Writer 丢弃，发 Gap ││ ││ 状态维护: ││ • Writer 为每个匹配的 Reader 维护 ReaderProxy (状态跟踪) │。
2026-04-26 21:49:50
29
原创 fastdds源码分析之DataWriter
│ DataWriter 实现功能总结 ││ ││ 主要职责: ││ • 数据发布 - write() / dispose() / unregister_instance() ││ • 序列化 - 调用 TypeSupport CDR 编码 ││ • 内存管理 - CacheChangePool / PayloadPool ││ • 可靠传输 - 配合 RTPSWriter 实现 Heartbeat/AckNack ││ • 实例管理 - 通过 key 标识和管理数据实例 │。
2026-04-26 19:35:15
41
原创 fastdds源码分析之WriterHistory
│ WriterHistory 作用总结 ││ ││ 核心作用: ││ 1. 存储 Writer 产生的所有数据变化 (CacheChange) ││ 2. 管理序列号分配和跟踪 ││ 3. 支持可靠传输的重传机制 ││ 4. 提供内存池化，优化性能 ││ 5. 与 StatefulWriter 配合，实现数据的可靠传输 ││ ││ 重要性: ││ • 没有 WriterHistory，Writer 无法实现可靠传输 ││ • 它是连接应用层数据和网络传输的桥梁 │。
2026-04-26 18:59:05
31
原创 fastdss源码分析之总体架构概述
│ Fast DDS 架构总结 ││ ││ 分层架构: ││ • 应用层 → DDS 层 → RTPS 层 → 传输层 → 物理网络层 ││ ││ 核心组件: ││ • DDS 层: DomainParticipant, DataWriter, DataReader ││ • RTPS 层: StatefulWriter, StatefulReader, 发现协议 ││ • 传输层: UDP, TCP, SharedMemory ││ ││ 关键特性: ││ • 发布-订阅模式 │。
2026-04-26 18:28:26
57
原创 fastdds源码分析之实例
│ instanceHandle 用户可见性 ││ ││ 本质: DDS 内部实现细节 ││ ││ 用户是否需要关心: ││ • 普通用法: 不需要 (write() 自动处理) ││ • 高级用法: 需要 (dispose, unregister, 指定实例) ││ ││ 推荐: ││ • 简单场景: 不管 instanceHandle，用 Key 字段区分实例 ││ • 复杂场景: 可以用 instanceHandle 精确控制实例生命周期 ││ │。
2026-04-26 16:08:24
49
原创 fastdds源码分析之CacheChange
/ 来自 CacheChange.hpp struct CacheChange_t {// 数据变化类型 (ALIVE, NOT_ALIVE_DISPOSED, etc.) ChangeKind_t kind;// 写入者的 GUID GUID_t writerGUID;// 实例句柄 InstanceHandle_t instanceHandle;// 序列号 SequenceNumber_t sequenceNumber;
2026-04-26 15:34:36
30
原创 fastdds源码分析之rtps协议分析
│ RTPS 协议内容总结 ││ ││ 消息格式: ││ ││ 子消息类型: ││ • 数据: DATA, DATA_FRAG ││ • 可靠: HEARTBEAT, ACKNACK, GAP, NACK_FRAG ││ • 发现: PARTICIPANT_DATA, PUBLICATION_DATA, SUBSCRIPTION_DATA ││ • 信息: INFO_TS, INFO_SRC, INFO_DST ││ ││ 核心概念: ││ • GUID - 全局唯一标识 │。
2026-04-26 13:02:44
34
原创 fastdds源码分析之fastdds概述
DDS 是(数据分发服务) 的缩写，是 OMG (对象管理组织) 制定的实时中间件标准。│ DDS 简介 ││ ││ • 组织: OMG (Object Management Group) ││ • 发布时间: 2004 (DDS 1.0) → 2015 (DDS 1.4) → 2023 (DDS 1.6) ││ • 定位: 数据为中心的发布-订阅中间件 (Data-Centric Publish-Subscribe) ││ ││ 应用场景: ││ • 机器人 (ROS 2) │。
2026-04-26 12:52:54
32
原创 fastdds源码分析之rtps协议概述
RTPS 是的缩写，是由 OMG (Object Management Group) 制定的DDS (Data Distribution Service) 有线协议标准。本质上讲，就是传输层之上的应用层协议，此处的传输层除了广义的tcp、udp之外，还包括了共享内存。│ OMG DDS 标准栈 ││ ││ │ DDS API (用户接口) │ ││ │ ││ ▼ ││ │ RTPS Protocol (有线协议) │ ││ │ │ ││ │ • 消息格式 │ │。
2026-04-26 12:43:26
38
原创 zmq源码分析之DEALER/ROUTER 路由机制的应用场景
DEALER/ROUTER 路由机制服务集群：实现负载均衡和水平扩展消息代理：构建灵活的消息路由系统异步 RPC：提高系统吞吐量和响应速度实时通信：聊天、游戏等实时系统金融交易：低延迟、高并发的交易系统物联网：管理大量设备的通信微服务：服务间的灵活通信这种模式的核心优势灵活的路由能力：基于路由 ID 精确路由异步通信：提高系统吞吐量负载均衡：自动分配任务可扩展性：轻松添加服务实例可靠性：故障自动检测和处理。
2026-04-25 23:14:28
47
原创 zmq源码分析之PUSH/PULL 模式的负载均衡分析
PUSH/PULL 模式的负载均衡轮询分发：PUSH 端使用轮询算法均匀分配消息动态调整：自动适应 PULL 端的增减无状态设计：简化实现，提高性能公平队列：PULL 端公平接收消息这种设计使得 PUSH/PULL 模式成为任务分发和并行处理的理想选择，能够有效地利用多进程或多线程的处理能力。
2026-04-25 23:08:03
241
原创 zmq源码分析之消息可读通知机制
ZeroMQ 检测完整消息可读并通知用户的机制消息解析decoder解析网络数据，检测完整消息消息存储：消息存储在 socket 的内部队列通知触发：通过signaler触发文件描述符的可读事件用户检测：用户通过poll或zmq_poll检测事件消息读取：调用zmq_recv读取消息这种设计确保了用户能够及时得知有消息可读，同时避免了忙等带来的性能损耗，是 ZeroMQ 高效通信的重要基础。
2026-04-25 23:01:20
327
原创 zmq源码分析之signaler_t
signaler_t是 ZeroMQ 中高效、跨平台的信号机制设计简洁只发送一个字节，最小化开销跨平台实现，支持不同操作系统功能强大支持线程间通知与 poll/select 无缝集成处理 fork 等特殊情况性能高效非阻塞设计最小化系统调用批量处理能力可靠性健壮的错误处理线程安全资源管理这种设计使得 ZeroMQ 能够高效地处理线程间通信，是其高性能的重要基础。
2026-04-25 22:54:01
305
原创 zmq源码分析之poller和signaler如何建立联动实现用户层通知
ZeroMQ 信号与 Poll 的配合机制信号发送当 socket 状态变化时（如收到消息），通过 signaler 发送信号信号检测zmq_poll 将 signaler 的文件描述符加入 poll 集合使用系统的 poll/select 等调用等待事件信号处理检测到 signaler 事件后，调用 signaler->recv() 清除信号然后检查所有 socket 的事件状态事件通知将有事件的 socket 通知给用户这种设计使得 ZeroMQ 能够高效、线程安全。
2026-04-25 22:51:47
331
原创 zmq源码分析之IO线程绑定时机
Socket 绑定到 IO 线程的过程创建阶段：选择 IO 线程并创建 socket连接阶段：创建 session 并与 IO 线程关联运行阶段：引擎注册到 IO 线程的 poller高效处理：IO 线程专门处理网络 I/O灵活扩展：通过增加 IO 线程数提高性能负载均衡：自动分配任务到负载较轻的线程这是 ZeroMQ 高性能网络通信的重要基础！
2026-04-25 22:31:58
320
原创 zmq源码分析之多 Socket 监听方案
连接多个 socket 并监听消息的最佳方案使用zmq_poller管理多个 socket一次等待多个 socket 的事件根据事件来源处理不同 socket 的消息单线程处理，避免线程复杂性这种方式比多线程更高效，代码更简洁，是 ZeroMQ 推荐的多 socket 管理方式！
2026-04-25 22:18:02
216
原创 zmq源码分析之session
Session 是 ZeroMQ 架构中的关键组件承上启下：连接 Socket（应用层）和 Engine（协议层）隔离保护：将复杂的网络操作隔离在 I/O 线程自动恢复：处理重连、错误恢复等复杂逻辑协议抽象：通过 engine 接口支持多种协议认证支持：集成 ZAP 认证机制生命周期管理：自动管理连接的创建和销毁设计哲学单一职责：一个 session 管理一个连接异步非阻塞：所有操作在 I/O 线程异步完成命令模式：通过命令队列实现跨线程通信状态机：清晰的状态转换逻辑可扩展性。
2026-04-25 22:05:01
355
原创 zmq源码分析之管道创建pipepair
特性说明无锁设计使用ypipe_t实现无锁队列，读写线程无需互斥锁双向通信两个独立的单向队列组成双向通道流量控制通过 HWM/LWM 实现背压机制，防止内存溢出聚合模式conflate 模式下只保留最新消息，适用于实时数据线程安全每个管道属于特定线程，通过命令模式跨线程通信延迟终止可选择等待消息处理完毕再销毁管道内存优化队列按粒度批量分配，减少内存分配次数pipepair是 ZeroMQ 消息传递的核心基础设施创建了两个pipe_t对象。
2026-04-20 10:06:18
62
原创 zmq源码分析之object_t
object_t是 ZeroMQ 中所有参与线程间通信的对象的基类，提供了线程间通信的基础设施和命令处理机制。public:// ... 其他方法object_t是 ZeroMQ线程间通信的核心基础设施基础类：所有参与线程间通信的对象的基类通信机制：提供统一的命令发送和处理机制线程标识：通过_tid标识对象所属线程全局访问：通过_ctx访问全局资源命令系统：支持多种命令类型的传递和处理它是 ZeroMQ 多线程架构的骨架。
2026-04-20 09:47:30
27
原创 zmq源码分析之tid
tid是 ZeroMQ 中线程标识的核心机制定义：线程 ID，标识对象所属的线程作用：用于线程间通信的路由和邮箱查找初始化：通过构造函数直接设置或从父对象继承使用：在命令发送、线程查找等场景中使用关系：与 slot 一一对应，是命令路由的关键tid 是 ZeroMQ 多线程架构的重要组成部分，确保了命令能够正确地发送到目标线程。
2026-04-20 09:45:54
41
原创 zmq源码分析之own_t
own_t是 ZeroMQ 中的对象所有权管理基类，负责管理对象的生命周期和所有权层次。它继承自object_t，是许多 ZeroMQ 核心组件的基类。own_t是 ZeroMQ对象生命周期管理的核心基类职责：管理对象的创建、所有权、终止和销毁机制：通过所有权树和引用计数确保正确清理应用：所有重要的 ZeroMQ 组件都继承自它流程：支持优雅的终止流程，确保资源正确释放线程安全：通过序列号和原子操作确保线程安全这是 ZeroMQ 能够避免内存泄漏和确保资源正确释放的关键机制！
2026-04-19 22:46:18
39
原创 zmq源码分析之两个特殊的线程
Termination 线程：负责协调上下文终止过程，确保所有操作有序完成Reaper 线程：负责资源回收，清理已关闭的 socket 和相关资源这两个线程的协作确保了 ZeroMQ 系统能够优雅地启动和终止，同时高效地管理资源，是 ZeroMQ 多线程架构的重要组成部分。
2026-04-19 22:41:17
40
原创 zmq源码分析之ctx
ctx是 ZeroMQ 的上下文，是整个 ZeroMQ 系统的核心管理组件资源管理：管理所有 socket、线程和其他资源线程管理：创建和管理 IO 线程池、reaper 线程Slot 分配：为所有线程分配唯一的 slot ID命令路由：通过 slot 实现线程间通信生命周期管理：处理上下文的启动和终止ctx是 ZeroMQ 的核心管理组件创建位置：通过在应用程序中创建使用位置Socket 创建和管理IO 线程和 reaper 线程管理Slot 分配和命令路由上下文生命周期管理。
2026-04-19 19:08:16
49
原创 zmq源码分析之slot
slots它是一个邮箱指针向量，用于存储系统中所有线程的邮箱地址，是 ZeroMQ 线程间通信的核心路由表。_slots_slots是 ZeroMQ 线程间通信的核心路由表数据结构存储所有线程的邮箱指针初始化：在中根据配置分配和初始化使用：通过 slot ID 快速查找邮箱，实现线程间命令传递管理：创建 socket 时分配 slot，销毁时释放 slot性能：O(1) 时间复杂度的邮箱查找，支持高效的线程间通信。
2026-04-19 18:59:33
33
原创 zmq源码分析之io_thread创建
创建时机：第一个 socket 创建时创建数量：由配置决定，默认为 1生命周期：与 ctx 相同，在 ctx 销毁时被清理启动流程：在中创建并启动停止流程：在中停止并销毁这种延迟创建的设计节省了资源，只有在真正需要时才创建 IO 线程。
2026-04-19 18:53:15
25
原创 zmq源码分析之io_thread_t
是 ZeroMQ 中的I/O线程，负责处理网络事件和命令传递。它是 ZeroMQ 多线程架构的核心组件，运行独立的事件循环来监听和处理各种文件描述符上的I/O事件。io_thread_t通过poller_t间接的持有线程，同时io_thread_t自身也持有了一个邮箱，用于接收外部命令，邮箱本身也是个文件描述符，io_thread_t自身的io事件也交给了poller_t管理。独立运行：每个 IO 线程运行在独立物理线程上事件驱动：通过 poller 监听文件描述符命令通道。
2026-04-19 18:05:04
34
原创 zmq源码分析之邮箱、命令与 IO 对象关系分析
邮箱作为命令的存储和传递通道命令作为组件间通信的消息单元IO 线程作为命令的处理者和事件的响应者上下文作为全局管理者，协调各组件的通信这种设计使得 ZeroMQ 能够在多线程环境中高效运行，同时保持代码的清晰性和可维护性。通过事件驱动和非阻塞 I/O，ZeroMQ 实现了高性能的消息传递系统，为分布式应用提供了可靠的通信基础。
2026-04-19 17:55:18
16
有初学C++ C linux 嵌入式的吗，这里集合，有大量系统学习的博客教程
2021-04-12
TA创建的收藏夹 TA关注的收藏夹
TA关注的人