- 博客(1280)
- 资源 (4)
- 问答 (1)
- 收藏
- 关注
RSS订阅
原创 Linux系统软件工程师/嵌入式Linux应用开发工程师 知识体系构建 500篇（持续更新）
今年受疫情影响，企业经营必不可免地受到冲击，企业在选人用人方面比以往都更加谨慎，招聘也更加苛刻。hr都试图用最低的成本去招最优秀的人才。本人从事嵌入式软件开发多年，结合自己的经验，推出了《嵌入式软件工程师技术面专题》，预计会有40篇，分成硬件协议、多进程多线程编程、网络编程、linux基础、C/C++等几大模块，每一篇在末尾都总结了相关提问，其中有些知识，即使是工作了两三年的同学也未必都懂，所以社招的同学也可以看，对于找工作绝对有帮助。**不打无准备之战，提前做好准备，方可立于不败之地**。欢迎大家订阅，只
2020-09-13 11:12:01
51654
73
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(3) 守护进程
守护进程(daemon)，是一种运行在后台 的特殊进程，它独立于控制终端 ，并周期性地执行某项任务或等待处理某些发生的事件。守护进程是个特殊的孤儿进程，这种进程脱离终端，为什么要脱离终端呢？之所以脱离于终端是为了避免进程被任何终端所产生的信息所打断，其在执行过程中的信息也不在任何终端上显示。由于在 Linux 中，每一个系统与用户进行交流的界面称为终端，每一个从此终端开始运行的进程都会依附于这个终端，这个终端就称为这些进程的控制终端，当控制终端被关闭时，相应的进程都会自动关闭。但是守护进程却能突破这种限制
2020-08-17 09:21:18
4140
4
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(4) 进程同步和通信的方式有哪些？
🥇 作者简介： 热衷于知识探索和分享的技术博主。💂 csdn主页:：【✍️ 微信公众号：【🎉精彩专栏：🎓 【 🧡 【 📚【 🌎【✍️ 【 …💂关于作者: 曾就职于国内知名安防上市公司，现就职于国内知名AMR机器人公司，担任高级系统软件工程师。2020年至今保持CSDN博客专家，CSDN C/C++领域优质创作者头衔。全网5万+粉丝。十载寒冰，难凉热血；多年过去，历经变迁，物是人非。然而，对于技术的探索和追求从未停歇。💪坚持创作，热衷分享，初心未改，继往开来！
2020-08-16 16:27:48
11565
2
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(15) 内核空间、用户空间、内核态、用户态
为了保证用户进程不能直接操作内核，保证内核安全，操作系统将虚拟空间划分为两部分，一部分是内核空间，一部分是用户空间。针对Linux操作系统，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF）供内核使用，称为内核空间，而较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。对于校招而言，该问题提问几率较大，因为是基础性问题，考察对内核空间和用户空间的理解，进程的内核态和用户态等概念。），进程切换时，用户空间切换，内核空间不变。
2020-08-16 16:18:39
15623
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
2643
2
原创 Linux C/C++ or 嵌入式面试之《多进程多线程编程系列》(1) 进程和线程的基本概念与区别
进程（Process）是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。程序是指令、数据及其组织形式的描述，进程是程序的实体。线程（thread）是操作系统能够进行调度的最小单位。它被包含在进程之中，一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。
2020-08-15 12:59:17
3852
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
15208
2
原创 机器人导航路径规划算法入门（6）Dijkstra（迪杰斯特拉）算法深入解析
我们前面介绍了BFS宽度优先算法，本质是按照距离逐层遍历，可以用来解决无权图最短路径查找，但是在有权图里，逐层查找，找到的路径就未必是最短路径了，因为可能会有其他比较绕的路径，但是累加起来的边距离更小。举一个通俗的例子，我到重庆比较近，假设重庆没有飞机场，只能坐高铁花费5小时。另外一个方案就是，我虽然离成都远，但是我可以坐飞机到，只要1小时，然后再从成都动车1小时到重庆。我不能说我从起点出发，看到直连重庆，就认为是最短路径，我还得继续看看离我稍远的邻居成都，通过成都走到重庆的代价是不是更短，这意味着，如果我
2026-09-16 11:18:40
133
原创 Jenkins Pipeline 各层级能放什么代码
"能不能写 Groovy 代码"只取决于你在不在script {}里面。其他层级（pipelinestagesstagesteps）都是声明式 DSL，只能按 Jenkins 规定的语法放对应的指令，不能自由写defiffor等 Groovy 代码。
2026-09-10 14:22:50
161
原创 机器人导航路径规划算法入门（3）BFS 广度优先搜索（Breadth-First Search）
BFS（广度优先搜索）最初是为了解决无权图的最短路径问题。当时 DFS 虽然能找到一条通路，但无法保证这条路径是步数最少的。BFS 逐层向外搜索，第一次到达目标点时，得到的就是最少步数的路径。核心思想：一层一层向外扩散搜索，先访问离起点近的节点，再访问更远的，像水波纹一样扩散。用**队列(Queue)**实现，先进先出。对比 DFS：深度优先是一条路走到黑再回溯；BFS是逐层遍历。
2026-09-10 11:11:17
279
原创 蓝牙配对（4）Numeric Comparison模式
Numeric Comparison 让“防中间人攻击”的成本降到最低——用户只需瞟一眼屏幕上的6位数字，并确认它们匹配，数学上就完成了一次不可伪造的端到端身份验证，是蓝牙配对中兼顾安全与易用性的黄金标准。
2026-08-09 11:30:53
46
原创 蓝牙配对（1）just work模式
后台自动跑完 ECDH 加密算法，前台只走一个无需输入数值的简单授权（甚至完全静默），以此换取极致的连接便捷性，同时明文告知你该连接不防中间人攻击。
2026-08-09 11:29:39
49
原创 蓝牙配对（0）配对流程详解
蓝牙配对（Pairing）是指两个蓝牙设备之间建立信任关系的过程，其核心目的是生成共享的链路密钥（Link Key），用于后续通信的加密和认证。而**绑定（Bonding）**则是指设备将配对过程中生成的密钥持久化存储，以便未来重连时无需再次配对。阶段协议特点传统配对Bluetooth 2.0 及更早使用 PIN Code（4~16位数字/字母），安全性较弱安全简单配对（SSP）使用 Passkey（6位数字）和多种关联模型，安全性大幅提升。
2026-08-09 11:26:27
54
原创 蓝牙配对（3）Passkey Entry 模型（显示方）
Passkey Entry 的显示方，角色极像“自动取款机（ATM）”：它负责把随机生成的 6 位交易码（Passkey）亮在屏幕上，并实时告诉用户“对方已敲了几位”，但完全不参与是否同意的裁决——裁决权完全交到了对面那个拿着键盘的人手里。
2026-08-09 11:24:39
41
原创 蓝牙配对（2）Passkey Entry 模型（输入方）
Passkey Entry 的输入方，角色极像“银行柜台前的顾客”：你不需要生成密码，只需要扭头看清柜员（显示方）举起的 6 位数字牌，然后低头在自己的密码器（键盘）上完整无误地敲进去并按下确认——一旦敲错，整个交易（配对）立即作废，必须从头再来。
2026-08-09 11:17:06
38
原创 fastdds源码分析之数据分发流程
✅EntityID 索引：使用哈希表按 EntityID 快速查找匹配的 Reader✅预注册机制：DataReader 创建时注册到 MessageReceiver✅一对多分发：支持一个 EntityID 对应多个 Reader✅回调分发：通过函数回调遍历处理所有匹配的 Reader✅安全检查：支持安全模式下的加密/解密检查✅零拷贝优化：DataSharing 模式避免内存拷贝。
2026-04-28 10:00:30
155
原创 fastdds源码分析之EDP协议
EDP是 RTPS 协议中用于发现端点（Writer/Reader）的协议，是 DDS 发现机制的核心部分。│ EDP 总结 ││ ││ 职责: 发现同 Participant 内所有的 Writer 和 Reader ││ ││ 使用内置主题: ││ • DCPSPublication - 发布者信息 ││ • DCPSSubscription - 订阅者信息 ││ ││ 依赖: PDP (先发现 Participant) ││ ││ 匹配条件: ││ • Topic 名称相同 │。
2026-04-26 22:40:43
211
原创 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
161
原创 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
176
原创 fastdds源码分析之Locator
│ Locator 总结 ││ ││ 本质: 网络地址 + 端口的抽象 ││ ││ 作用: ││ • 定位目标 (UDP/TCP/SHM) ││ • 统一不同传输协议的地址表示 ││ • 用于发送和接收数据 ││ ││ 特点: ││ • 支持 IPv4/IPv6/SHM/Ethernet ││ • kind 区分传输类型 ││ • 16 字节地址支持 IPv6 ││ │。
2026-04-26 21:58:41
141
原创 fastdds源码分析之可靠传输机制分析
│ 可靠传输机制总结 ││ ││ 核心机制: ││ 1. 周期性发送 Heartbeat (100ms) ││ 2. Reader 收到 Heartbeat 后，比较自己历史，发 AckNack ││ 3. Writer 收到 AckNack 后，重传缺失数据 ││ 4. 如果一些数据被 Writer 丢弃，发 Gap ││ ││ 状态维护: ││ • Writer 为每个匹配的 Reader 维护 ReaderProxy (状态跟踪) │。
2026-04-26 21:49:50
79
原创 fastdds源码分析之DataWriter
│ DataWriter 实现功能总结 ││ ││ 主要职责: ││ • 数据发布 - write() / dispose() / unregister_instance() ││ • 序列化 - 调用 TypeSupport CDR 编码 ││ • 内存管理 - CacheChangePool / PayloadPool ││ • 可靠传输 - 配合 RTPSWriter 实现 Heartbeat/AckNack ││ • 实例管理 - 通过 key 标识和管理数据实例 │。
2026-04-26 19:35:15
117
原创 fastdds源码分析之WriterHistory
│ WriterHistory 作用总结 ││ ││ 核心作用: ││ 1. 存储 Writer 产生的所有数据变化 (CacheChange) ││ 2. 管理序列号分配和跟踪 ││ 3. 支持可靠传输的重传机制 ││ 4. 提供内存池化，优化性能 ││ 5. 与 StatefulWriter 配合，实现数据的可靠传输 ││ ││ 重要性: ││ • 没有 WriterHistory，Writer 无法实现可靠传输 ││ • 它是连接应用层数据和网络传输的桥梁 │。
2026-04-26 18:59:05
157
原创 fastdss源码分析之总体架构概述
│ Fast DDS 架构总结 ││ ││ 分层架构: ││ • 应用层 → DDS 层 → RTPS 层 → 传输层 → 物理网络层 ││ ││ 核心组件: ││ • DDS 层: DomainParticipant, DataWriter, DataReader ││ • RTPS 层: StatefulWriter, StatefulReader, 发现协议 ││ • 传输层: UDP, TCP, SharedMemory ││ ││ 关键特性: ││ • 发布-订阅模式 │。
2026-04-26 18:28:26
183
原创 fastdds源码分析之实例
│ instanceHandle 用户可见性 ││ ││ 本质: DDS 内部实现细节 ││ ││ 用户是否需要关心: ││ • 普通用法: 不需要 (write() 自动处理) ││ • 高级用法: 需要 (dispose, unregister, 指定实例) ││ ││ 推荐: ││ • 简单场景: 不管 instanceHandle，用 Key 字段区分实例 ││ • 复杂场景: 可以用 instanceHandle 精确控制实例生命周期 ││ │。
2026-04-26 16:08:24
107
原创 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
154
原创 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
166
原创 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
315
原创 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
173
原创 zmq源码分析之DEALER/ROUTER 路由机制的应用场景
DEALER/ROUTER 路由机制服务集群：实现负载均衡和水平扩展消息代理：构建灵活的消息路由系统异步 RPC：提高系统吞吐量和响应速度实时通信：聊天、游戏等实时系统金融交易：低延迟、高并发的交易系统物联网：管理大量设备的通信微服务：服务间的灵活通信这种模式的核心优势灵活的路由能力：基于路由 ID 精确路由异步通信：提高系统吞吐量负载均衡：自动分配任务可扩展性：轻松添加服务实例可靠性：故障自动检测和处理。
2026-04-25 23:14:28
217
原创 zmq源码分析之PUSH/PULL 模式的负载均衡分析
PUSH/PULL 模式的负载均衡轮询分发：PUSH 端使用轮询算法均匀分配消息动态调整：自动适应 PULL 端的增减无状态设计：简化实现，提高性能公平队列：PULL 端公平接收消息这种设计使得 PUSH/PULL 模式成为任务分发和并行处理的理想选择，能够有效地利用多进程或多线程的处理能力。
2026-04-25 23:08:03
373
原创 zmq源码分析之消息可读通知机制
ZeroMQ 检测完整消息可读并通知用户的机制消息解析decoder解析网络数据，检测完整消息消息存储：消息存储在 socket 的内部队列通知触发：通过signaler触发文件描述符的可读事件用户检测：用户通过poll或zmq_poll检测事件消息读取：调用zmq_recv读取消息这种设计确保了用户能够及时得知有消息可读，同时避免了忙等带来的性能损耗，是 ZeroMQ 高效通信的重要基础。
2026-04-25 23:01:20
413
原创 zmq源码分析之signaler_t
signaler_t是 ZeroMQ 中高效、跨平台的信号机制设计简洁只发送一个字节，最小化开销跨平台实现，支持不同操作系统功能强大支持线程间通知与 poll/select 无缝集成处理 fork 等特殊情况性能高效非阻塞设计最小化系统调用批量处理能力可靠性健壮的错误处理线程安全资源管理这种设计使得 ZeroMQ 能够高效地处理线程间通信，是其高性能的重要基础。
2026-04-25 22:54:01
386
原创 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
377
原创 zmq源码分析之IO线程绑定时机
Socket 绑定到 IO 线程的过程创建阶段：选择 IO 线程并创建 socket连接阶段：创建 session 并与 IO 线程关联运行阶段：引擎注册到 IO 线程的 poller高效处理：IO 线程专门处理网络 I/O灵活扩展：通过增加 IO 线程数提高性能负载均衡：自动分配任务到负载较轻的线程这是 ZeroMQ 高性能网络通信的重要基础！
2026-04-25 22:31:58
400
原创 zmq源码分析之多 Socket 监听方案
连接多个 socket 并监听消息的最佳方案使用zmq_poller管理多个 socket一次等待多个 socket 的事件根据事件来源处理不同 socket 的消息单线程处理，避免线程复杂性这种方式比多线程更高效，代码更简洁，是 ZeroMQ 推荐的多 socket 管理方式！
2026-04-25 22:18:02
260
原创 zmq源码分析之session
Session 是 ZeroMQ 架构中的关键组件承上启下：连接 Socket（应用层）和 Engine（协议层）隔离保护：将复杂的网络操作隔离在 I/O 线程自动恢复：处理重连、错误恢复等复杂逻辑协议抽象：通过 engine 接口支持多种协议认证支持：集成 ZAP 认证机制生命周期管理：自动管理连接的创建和销毁设计哲学单一职责：一个 session 管理一个连接异步非阻塞：所有操作在 I/O 线程异步完成命令模式：通过命令队列实现跨线程通信状态机：清晰的状态转换逻辑可扩展性。
2026-04-25 22:05:01
449
原创 zmq源码分析之管道创建pipepair
特性说明无锁设计使用ypipe_t实现无锁队列，读写线程无需互斥锁双向通信两个独立的单向队列组成双向通道流量控制通过 HWM/LWM 实现背压机制，防止内存溢出聚合模式conflate 模式下只保留最新消息，适用于实时数据线程安全每个管道属于特定线程，通过命令模式跨线程通信延迟终止可选择等待消息处理完毕再销毁管道内存优化队列按粒度批量分配，减少内存分配次数pipepair是 ZeroMQ 消息传递的核心基础设施创建了两个pipe_t对象。
2026-04-20 10:06:18
131
原创 zmq源码分析之object_t
object_t是 ZeroMQ 中所有参与线程间通信的对象的基类，提供了线程间通信的基础设施和命令处理机制。public:// ... 其他方法object_t是 ZeroMQ线程间通信的核心基础设施基础类：所有参与线程间通信的对象的基类通信机制：提供统一的命令发送和处理机制线程标识：通过_tid标识对象所属线程全局访问：通过_ctx访问全局资源命令系统：支持多种命令类型的传递和处理它是 ZeroMQ 多线程架构的骨架。
2026-04-20 09:47:30
160
有初学C++ C linux 嵌入式的吗，这里集合，有大量系统学习的博客教程
2021-04-12
TA创建的收藏夹 TA关注的收藏夹
TA关注的人