- 博客(587)
- 收藏
- 关注
RSS订阅原创 Spring Boot 用户注册接口（含事务 + 参数校验）
当我们把查询接口跑通之后，下一步最自然的就是：❗实现一个真正的用户注册接口接参数判空查数据库插数据返回结果这样能跑，但很快就会乱。这篇文章，我带你用一个更规范、更接近企业项目参数校验事务控制❗ 一个合格的注册接口，不只是“能插入数据库”，而是要同时考虑：参数是否合法事务是否安全返回是否统一异常是否可控。
2026-04-18 17:28:30
278
原创 Spring Boot 企业级分层中，User 为什么不再用 entity？（一文讲透 DO / Model / DTO）
摘要：文章探讨了SpringBoot+MyBatis项目中对象分层的重要性。小项目可以使用单一entity类，但企业级项目必须拆分职责：UserDO（数据库对象）、User（领域对象）和DTO（接口对象）。这种分层解决了字段污染、业务混乱和扩展困难等问题，通过Assembler实现对象转换。结论指出，entity适合简单项目，而分层模型更适合复杂业务系统。最后建议初学者从entity入手，进阶开发者应采用分层架构。
2026-04-17 19:11:16
292
原创 Spring Boot + MyBatis 从 0 到 1 跑通查询接口（含全部踩坑）
本文详细介绍了如何从零开始搭建一个SpringBoot+MyBatis的查询接口，实现通过ID查询用户信息。内容包括：数据库准备、依赖引入、配置文件设置、实体类与Mapper接口创建、XML映射文件编写、Service和Controller实现等完整步骤。重点强调了MyBatis配置中的常见问题，如Mapper扫描、XML路径、命名空间一致性等关键点。通过本文，开发者可以掌握SpringBoot整合MyBatis的核心要点，避免常见配置错误，实现从浏览器请求到数据库查询的完整链路。文章最后还预告了下一篇将介
2026-04-17 19:08:40
32
原创 Spring Boot 中 @Autowired、构造器注入、@Mapper 的本质区别（一次讲透）
本文深入解析了SpringBoot中依赖注入的核心原理与实践规范。首先阐明Spring容器的本质是管理Bean对象及其依赖关系，重点讲解了MyBatis如何通过生成代理对象将Mapper接口注册为Spring Bean。文章对比了字段注入和构造器注入两种方式，详细论证了构造器注入在对象完整性、依赖清晰度和安全性方面的优势。同时介绍了企业级项目中常用的@MapperScan注解及其最佳实践，推荐采用构造器注入+final+Lombok的统一规范。最后强调Controller-Service-Mapper三层架
2026-04-17 19:02:46
443
原创 Spring Boot 核心机制之 @Conditional：从原理到实战（一次讲透）
👉@Conditional = 条件装配机制根据条件，决定某个 Bean 是否被加载到 Spring 容器中@Conditional 的本质：↓控制 Bean 是否存在发生时机：↓容器启动 → 注册 BeanDefinition 阶段适用场景：↓功能开关 / 自动配置 / 模块控制不适用：↓用户权限判断。
2026-04-17 17:26:16
283
原创 Spring 启动到底干了什么？一文讲清 Bean 创建 + 依赖注入全过程
Spring的核心机制可概括为两件事：创建对象（Bean）和组装对象关系（依赖注入）。启动时通过@ComponentScan扫描包，自动创建@Component等注解标记的类实例，或通过@Configuration+@Bean手动定义对象，并将它们存入类似Map的容器中。@Autowired实现依赖注入时，会按类型查找容器中的Bean并自动装配。整个过程本质是自动化的对象管理和关系维护，消除了手动new和装配的繁琐。理解这一机制后，@Component、@Autowired等注解不再神秘，也为理解事务、AO
2026-04-16 19:06:34
551
原创 Spring Boot 实战（四）：MySQL + MyBatis 接入，打通用户注册最小闭环
Spring Boot 项目创建Controller 接口开发DTO 参数接收与校验Service 分层Result 统一返回全局异常处理日志但目前还有一个核心问题：数据没有真正落库也就是说，现在的接口只是“能跑”，但还不是真正的后端系统。本篇开始，我们接入：把项目真正打通成：新建：@Data新建：@MapperMySQL 没启动数据库不存在用户名密码错误没加 MySQL 驱动。
2026-04-15 22:54:20
322
原创 Spring Boot 实战（五）：接口工程化升级（统一返回 + 异常处理 + 错误码体系 + 异常流转机制）
请求→ Service→ Mapper→ MySQL→ 返回结果到这一步，项目已经不是 Demo 了，而是一个能跑通完整链路的最小后端项目。1. 返回结构还不够规范2. 异常处理还不够分层3. 错误码体系还没有建立4. 业务异常和系统异常没有彻底区分5. 对“异常是怎么流转的”理解还不够完整前端不知道怎么判断失败类型接口返回风格不统一业务报错和系统报错混在一起Controller 代码越来越乱try-catch 到处都是问题排查越来越难。
2026-04-15 18:01:02
395
原创 Spring 核心思想解析：IoC 与 DI 一文讲透（从入门到工程理解）
本文系统讲解了IoC（控制反转）与DI（依赖注入）的核心概念。传统开发中程序员需手动创建对象（new），存在强耦合、不易扩展等问题。而Spring通过IoC将对象控制权交给容器，DI则实现依赖关系的自动注入。IoC是设计思想，DI是其主流实现方式，二者共同实现解耦、可扩展的系统架构。关键点在于面向接口编程，开发者只需声明依赖接口，Spring自动注入具体实现。这种模式降低了代码耦合度，提升了可维护性和可测试性，是现代Java开发的重要思想跃迁。
2026-04-15 13:51:58
420
原创 Spring Boot 实战（三）：Service 分层 + 统一返回 + 异常处理（工程级写法）
Controller 接口开发DTO 参数接收@Valid 参数校验Controller 承担了业务逻辑 ❌返回结构不统一 ❌没有异常处理 ❌没有日志 ❌👉 本篇将完成一次工程级升级通过 Service 分层、统一返回结构和全局异常处理，可以将简单接口升级为具备工程规范的后端系统。
2026-04-15 12:04:12
147
原创 Spring Boot 接口设计进阶：POST / PUT / DELETE 的本质区别与工程实践
本文探讨了HTTP方法POST/PUT/DELETE的区别及其规范使用的意义。从代码层面看，这些方法实现相似，但本质区别在于语义和幂等性：POST用于创建（不幂等），PUT用于更新（幂等），DELETE用于删除（幂等）。规范使用HTTP方法具有重要工程价值，包括网络重试安全、日志可读性、系统支持等。尽管实际项目中存在不规范使用的情况（如全部用POST），但遵循REST规范（URL表示资源，HTTP方法表示操作）能提升代码的语义清晰度和可维护性。这体现了从"写代码"到"做工程&q
2026-04-14 18:39:58
240
原创 Spring Boot 入门实战（二）：用户注册接口设计（Controller + DTO + Validation）
本文介绍了使用SpringBoot开发用户注册接口的完整流程。通过Controller+DTO+Validation构建了一个具备参数接收和校验能力的最小接口闭环。重点讲解了DTO设计（@Data、@NotBlank）、Controller实现（@RestController、@PostMapping、@RequestBody、@Valid）等核心内容，并详细说明了各注解的作用及配合关系。文章还提供了接口测试方法、常见错误排查及命名规范建议，完整呈现了一个标准后端接口从请求接收到参数校验的全过程。最后总结了
2026-04-14 18:16:09
209
原创 Spring Boot 入门实战（一）：项目创建与运行机制详解
本文从工程视角解析SpringBoot项目的核心运行逻辑。SpringBoot本质是自带服务器的后端应用，通过pom.xml定义项目能力（如引入Web、数据库等模块），application.yml配置运行时参数（端口、数据库连接等）。项目启动后初始化Spring容器并运行内嵌Tomcat，需通过Controller手动映射接口，否则访问8080端口会返回404。文章重点分析了典型问题：数据库连接失败源于未配置却引入JPA依赖，端口冲突需终止占用进程。同时介绍了Lombok消除样板代码的价值，并梳理出完整开
2026-04-13 18:07:21
335
原创 一文讲透：Linux / Android / Java 后端三大体系分层关系（系统层认知终极总结）
本文系统对比了Linux原生、Java后端和Android三大技术体系的核心架构差异：Linux应用直接通过系统调用操作内核（C/C++），Java后端依赖JVM执行（SpringBoot），Android则通过Framework封装系统服务（Kotlin/Java）。重点指出硬件驱动（如CAN/串口）位于Linux内核层，Android需通过HAL层间接访问。文章强调理解系统层级关系对开发者成长至关重要：从应用层深入系统层（Framework），最终掌握Linux底层开发（驱动/内核），才能实现从&quo
2026-04-11 22:18:12
373
1
原创 C++对象模型一图通：虚函数 vs 虚继承（vptr / vbptr 全部讲透）
C++中虚函数和虚继承的核心机制对比 摘要： 虚函数通过vptr（虚函数指针）和虚函数表实现运行时多态，解决"调用哪个函数"的问题；虚继承通过vbptr（虚基类指针）和偏移表解决菱形继承中的数据冗余问题，处理"数据保留几份"的问题。两者本质都是通过指针间接层来解耦结构：虚函数实现行为多态（动态绑定），虚继承实现数据共享（单一基类实例）。关键区别在于vptr指向函数地址表，而vbptr指向基类位置偏移表。这种间接访问机制是C++对象模型的核心设计思想，但需注意虚函数常用
2026-04-09 18:43:21
271
原创 C++对象模型一图通：this / static / const / inline 全部讲透
本文系统梳理了C++对象模型的核心机制：1）成员函数本质是带this指针的普通函数（func(Athis)）；2）const成员函数即func(constAthis)；3）static成员没有this指针，变量需类外定义以避免多重定义；4）inline关键字解决链接时的重复定义问题。通过揭示this指针、static存储、inline机制等底层逻辑，将原本零散的知识点串联成对象模型、内存模型和编译链接模型三层架构。掌握这些核心原理，能从根本上理解C++的运作机制，使复杂语法变得清晰可循。
2026-04-08 18:14:27
643
原创 C++ 编译模型与工程机制全解析：从 include 到链接与 ABI
本文深入解析C++编译模型的核心机制，帮助Java/Android开发者理解C++工程本质。关键点包括：1）#include本质是文本复制而非模块导入；2）编译检查语法正确性，链接检查实现完整性；3）声明与定义分离原则；4）静态库与动态库的特性差异；5）ABI对二进制兼容的决定作用。文章建立了完整的工程排错模型：编译错误检查语法，链接错误检查实现缺失，运行时错误检查库依赖。最终指出：掌握C++工程的核心在于理解从代码到程序的完整转换过程，这种认知能显著提升问题定位能力和工程思维水平。
2026-04-07 16:03:32
299
原创 C/C++ 混编与工程边界：从 name mangling 到 C API 设计
C/C++混编的核心在于利用C作为稳定接口层，C++实现复杂逻辑层。关键问题源于C++的name mangling机制（为支持函数重载而修改函数名），导致C无法识别。解决方案是使用extern "C"声明，使C++函数按C方式导出（禁用重载）。工程标准模式为：外部通过C API调用，内部用C++实现，头文件作为接口声明。这种模式在跨语言开发（如NDK/JNI）和系统层开发中尤为重要。本质上是将C++的强大功能与C的稳定接口相结合，构建清晰的工程边界。
2026-04-07 14:13:14
313
原创 从 Reactor 到 HashMap：一条打通事件驱动与复杂度的学习链路
本文系统梳理了C++服务端开发中Reactor模型的核心知识链路。首先指出理解事件驱动模型需要打通从epoll机制到数据结构性能的完整认知。重点解析了Reactor的三层架构（epoll发现事件、Reactor分发事件、handler处理事件）和动态注册机制，澄清了epoll"状态变化才通知"的工作特性。通过复杂度分析(O(1)/O(n))，论证了unordered_map在快速查找中的关键作用，并与红黑树实现(map)进行对比。最终提炼出高并发系统的本质：事件驱动+O(1)查找+数据结
2026-04-06 14:49:55
257
原创 C++ 服务端进阶（六）—— 工程化落地：协议、缓冲区与超时机制（最终闭环篇）
本文介绍了如何将基于多Reactor和协程的高并发服务端模型工程化，使其具备实际可用性。主要内容包括：1) 引入缓冲区管理解决半包/粘包问题；2) 设计简单协议格式[消息长度+内容]；3) 实现超时机制自动回收空闲连接；4) 确保资源安全释放的生命周期控制。通过Connection类升级，实现了从socket→读缓冲→解析→写缓冲的完整数据处理流程，并添加定时扫描机制自动清理超时连接。最终使系统在保持高性能架构的同时，具备了协议解析、数据完整性、连接可控性和资源安全性等工程必备特性，完成了从理论模型到生产可
2026-04-06 08:38:08
27
原创 C++ 服务端进阶（五）—— Connection + 协程：面向对象的异步模型（工程版完整实现）
本文实现了从函数式异步到面向对象异步的架构升级，核心将连接处理逻辑封装为Connection对象。相比第四篇的多Reactor+协程架构，第五篇通过Connection类实现了： 连接实体化，包含fd、缓冲区和协程执行逻辑 生命周期自主管理，提供closeSelf()接口 协程逻辑内聚，通过run()方法实现异步读写 代码结构优化，删除Server类，新增Connection类 最终形成"fd→Connection对象→协程→IO操作"的完整处理链，使连接成为具备完整异步能力的服务端实体
2026-04-06 08:30:06
336
原创 C++ 服务端进阶（四）—— 多 Reactor + 协程：真正的高并发模型（融合版）
本文构建了一个现代高并发服务端架构模型，将多Reactor并发模型与协程执行模型相结合。核心设计采用主Reactor负责accept连接，多个子Reactor线程处理IO事件，每个子Reactor内部使用协程执行具体任务。该架构实现了多核利用、无锁并发（通过连接绑定固定线程）和高性能处理。关键技术包括：线程独立的事件循环、协程不跨线程恢复、主Reactor仅负责连接接收。最终形成的模型融合了epoll事件驱动、Reactor调度、多线程并发和协程执行等现代服务端核心技术。
2026-04-06 07:35:58
645
原创 C++ 服务端进阶（三）—— Reactor + 协程：现代异步模型（附完整项目结构与代码）
本文探讨如何将C++20原生协程与epoll和Reactor模式结合，构建最小可运行版本。作者指出C++协程仅提供基本机制，需自行整合事件循环、协程恢复等组件。通过Reactor调度epoll事件，协程实现同步式异步编程，解决回调地狱问题。文章详细设计了项目结构，包含Task、Reactor、SocketUtil等模块，重点阐释DetachedTask的作用和Reactor保存协程句柄的必要性。最终实现echo server示例，展示"同步写法+异步执行"的协程优势，完整呈现epoll→
2026-04-03 17:59:33
339
原创 C++ 服务端进阶（二）—— 多 Reactor + 线程模型：高并发服务端架构（工程版）
本文介绍了从单Reactor模型升级到多Reactor+多线程模型的必要性及实现方法。单Reactor模型存在CPU利用率低、无法充分利用多核等问题，而多Reactor模型通过主线程负责accept、子线程独立处理连接的方式解决了这些问题。关键实现包括：1) ReactorThread封装线程和Reactor；2) ReactorThreadPool实现连接负载均衡；3) Acceptor将新连接分发给子Reactor。这种架构避免了锁竞争，提高了并发性能，是Nginx/Netty等工业级应用的核心模型。最
2026-04-03 16:12:51
296
原创 C++ 服务端进阶（一）—— 从 Reactor 到 Connection：服务骨架设计（工程版）
本文介绍了如何将基于lambda的简单Reactor模式升级为面向对象的Connection模型。通过建立EventHandler抽象接口，实现了Reactor、Acceptor和Connection的三层架构：Reactor作为调度层统一管理事件循环，Acceptor负责接入新连接，Connection处理具体连接的读写和生命周期。这种架构解决了函数式demo在状态管理、缓冲区处理等方面的不足，形成了标准的服务端骨架，为后续扩展多Reactor、线程模型等高级功能奠定了基础。文章详细展示了各个组件的实现，
2026-04-03 15:17:34
294
原创 C++ 高性能服务端进阶路线—— 从 epoll + Reactor 到多线程与协程的系统化路径
本文系统梳理了C++高并发服务端的进阶路线，将其划分为6个关键阶段：1）Reactor工程化（Connection模型）；2）多Reactor+线程模型；3）Reactor+协程；4）多Reactor+协程融合；5）Connection+协程优化；6）工程化落地。通过"能力拆解-融合-优化"的递进方式，帮助开发者从基础epoll/Reactor出发，逐步构建包含连接抽象、并发架构、异步执行等完整要素的高并发系统，最终实现从理论模型到工程落地的闭环。
2026-04-03 12:49:00
296
原创 C++ 并发核心模型总结—— 从阻塞 IO 到 Reactor + 协程的完整理解（附 mini epoll + Reactor demo）
本文系统讲解了C++网络编程中的核心概念：阻塞IO（线程等待数据）、非阻塞IO（线程不等待）、epoll（事件通知机制）、Reactor（事件调度模型）和协程（可暂停执行的代码）。通过一个miniReactor示例，展示了如何用epoll监听事件、Reactor调度处理、handler执行业务逻辑的整体流程。关键点在于理解：epoll负责发现事件，Reactor负责调度事件，协程/Handler负责执行具体任务。这种架构实现了高效的事件驱动编程模式，为后续学习多Reactor、线程池等高级特性奠定了基础。
2026-04-03 12:43:03
682
原创 C++ 高性能网络服务骨架（四）—— 从阻塞模型到 Reactor：服务端并发模型进阶
本文探讨如何用更少线程处理更多连接，突破传统"一个连接一个线程"的瓶颈。首先分析三种模型：单线程阻塞（串行处理）、线程池+阻塞IO（线程被占用）、服务骨架（仍使用阻塞IO）。核心问题在于线程被阻塞，解决方案是采用非阻塞IO配合epoll事件通知机制，实现从"线程绑定连接"到"线程绑定事件"的转变。文章详细介绍了epoll工作原理和Reactor事件驱动模型，指出高并发的本质在于调度方式而非线程数量。最终形成完整认知闭环：线程池解决执行问题，epol
2026-04-03 00:03:47
340
原创 C++ 高性能网络服务骨架（三）—— 请求分发、连接处理与服务骨架设计
本文介绍了一个C++服务端架构的优化过程，将原本混杂网络IO和业务逻辑的代码重构为清晰的职责分层结构。通过定义Request/Response对象、Parser解析器、Dispatcher分发器和Encoder编码器等组件，构建了完整的请求处理流水线：ConnectionHandler→RequestParser→RequestDispatcher→ResponseEncoder。这种分层设计解决了原始版本的结构混乱、缺乏错误处理等问题，使业务逻辑脱离网络细节，为后续添加日志、鉴权等功能奠定了基础。虽然当前
2026-04-02 17:53:15
343
1
原创 C++ 高性能网络服务骨架（二）—— 线程池接入：accept 与 worker 分离
本文介绍了如何将单线程TCP服务端升级为多线程并发模型。核心改进是将主线程的accept操作与请求处理解耦：主线程只负责接收连接，将客户端socket描述符提交到线程池队列，由worker线程执行实际的read/write/close操作。这种架构解决了串行处理导致的阻塞问题，实现了基本并发能力。文章详细说明了改造要点、完整代码实现和工作流程，并指出该模型仍存在线程数量限制和阻塞IO的瓶颈。最终强调服务端的本质是连接接入层与执行层的分离，为后续更高级的IO模型和连接管理奠定基础。
2026-04-02 15:38:12
26
原创 C++ 高性能网络服务骨架（一）—— 从 0 搭一个最小 TCP 服务端（阻塞版）
摘要： 本文从最基础的TCP服务端实现入手，强调理解网络编程核心流程的重要性。通过一个可运行的C++最小TCP服务端示例（包含socket创建、bind、listen、accept及read/write流程），演示单次请求的完整链路：客户端连接→请求读取→响应返回→连接关闭。代码虽简单（串行处理单连接），但揭示了服务端本质——循环接收并处理连接。同时指出其缺陷（无法并发），为后续线程池优化埋下伏笔。对比Java的ServerSocket实现，说明不同语言下网络编程核心逻辑的一致性。最终目标是帮助读者从底层理
2026-04-02 14:54:58
318
原创 一篇讲透线程池核心代码：从 submit 到执行链路（含 lambda / move / packaged_task）
submit 做三件事：1. 包装任务（f → packaged_task）2. 获取结果（future）3. 入队执行（lambda → tasks_）👉这段代码 = 线程池“任务提交接口”的最小闭环实现任务如何进入线程池任务如何执行结果如何返回。
2026-04-02 12:26:50
389
原创 从 std::function 到 Future：一篇讲透 C++ / Java / Kotlin 的统一并发模型
本文揭示了C++、Java和Kotlin三种语言在并发编程中的统一模型：函数（行为）、调度（线程池）和结果（Future）。通过分析回调函数与任务模型的区别，指出回调是调用时传参，而任务通过闭包捕获参数。深入讲解了C++中的引用和lambda捕获机制，以及线程池的任务队列本质。最终提出统一认知：三种语言的并发实现本质相同，只是语法差异。掌握这套模型后，可以融会贯通地理解不同语言的并发编程特性。
2026-04-01 21:12:18
404
原创 C++ 网络服务端主线：从线程池到 Reactor 的完整路线图
本文介绍了C++网络服务骨架系列的学习路线。作者强调应先从基础入手，通过4篇文章逐步构建完整的服务端系统思维：首先实现单线程阻塞版TCP服务端，理解基本流程；然后将线程池接入实现请求处理；接着完善请求分发与连接管理；最后升级到Reactor模型。这条从线程池到网络连接再到并发模型的主线，旨在帮助开发者建立从"并发组件"到"服务端系统"的完整认知结构，为后续学习高并发模型打下坚实基础。
2026-04-01 14:57:20
967
原创 从 0 手写一个工业级线程池（支持 future + 拒绝策略 + 优雅关闭）—— C++ 多线程与并发系统取向（实战篇）
本文介绍了C++线程池的实现原理与工程实践。主要内容包括：1）线程池的核心价值在于控制线程数量、解耦任务提交与执行；2）系统设计要点包括线程模型、共享资源保护、状态控制等；3）关键机制如future/packaged_task实现异步结果获取；4）工程实现必须包含有界队列和拒绝策略（如抛异常、丢弃任务等）来处理系统过载；5）完整代码展示了线程池的线程循环、任务提交、优雅关闭等功能。文章强调线程池本质是任务调度系统，需要正确处理并发控制、资源管理和背压机制。通过实现这个并发组件，开发者可以达到C++并发编程的
2026-04-01 13:45:48
604
原创 从 0 开始讲透 C++ 并发（七）：排障与工程纪律（死锁 / 性能 / 设计规范[特殊字符]）
本文系统总结了并发编程中的常见陷阱与解决方案。主要内容包括：1）死锁问题及通过固定加锁顺序或std::lock解决；2）锁范围过大会导致性能下降，应最小化锁定区域；3）数据竞争需通过mutex或atomic保护；4）条件变量使用必须搭配条件检查；5）避免锁嵌套和atomic误用；6）线程必须join。文章强调并发编程的核心原则是安全优先于性能，并提出了6条工程纪律，包括使用RAII、最小化锁范围等。最后指出掌握这些内容意味着具备了完整的并发工程能力，核心是在多执行流中确保数据正确性和执行有序性。
2026-03-30 22:38:46
277
原创 从 0 开始讲透 C++ 并发（五·进阶终版）：CAS vs mutex（无锁与加锁的本质区别）
并发编程中，CAS（比较并交换）是一种无锁同步机制，通过原子操作实现线程安全。相比传统加锁方案（mutex），CAS避免了线程阻塞和上下文切换的开销，在低竞争场景下性能更优。其核心是"读取-比较-更新"的循环重试机制：失败时仅需CPU级重试（纳秒级），而非操作系统级的线程调度（微秒级）。但CAS适用于简单操作（如计数器），在高竞争时会导致CPU自旋消耗。工程实践中应权衡选择：低冲突用CAS，高冲突用mutex，复杂逻辑仍需加锁。还需注意ABA问题，可通过版本号解决。
2026-03-30 22:25:36
327
原创 从 0 开始讲透 C++ 并发（六）：线程池（任务系统骨架）简单入门
《线程池原理与C++实现解析》 摘要：线程池通过复用线程资源解决频繁创建销毁的性能损耗问题。其核心结构包含：1）工作线程组执行任务；2）任务队列存储待处理任务；3）互斥锁保护共享资源；4）条件变量实现线程协作。采用生产者-消费者模型，当任务提交时入队并唤醒线程，空闲线程通过条件变量等待任务。C++实现需注意unique_lock配合条件变量的使用，与Java的ExecutorService机制类似。线程池技术标志着从基础并发编程到工程实践的跨越，后续将深入死锁防范和性能优化等进阶主题。（149字）
2026-03-30 17:56:55
251
原创 从 0 开始讲透 C++ 并发（五）：atomic（无锁并发彻底讲透）
本文探讨了并发编程中锁的替代方案——原子操作(atomic)。首先指出锁(mutex)虽然能保证线程安全，但存在性能开销、上下文切换和死锁风险等问题。然后介绍了原子操作的核心特性：通过硬件级支持确保操作的不可分割性，适用于简单变量操作(如计数器、状态标志)。文章对比了atomic与mutex的差异：atomic无需加锁、性能更高但只适合简单场景，mutex则适用于复杂逻辑。最后总结了C++并发编程的四大核心组件(thread、mutex、cv、atomic)及其各自作用，指出atomic是实现无锁线程安全的
2026-03-30 17:42:32
212
原创 从 0 开始讲透 C++ 并发（四）：condition_variable 机制 + 完整案例 + Java 对比
C++并发编程中的线程协作机制：condition_variable详解 本文深入讲解了C++并发编程中线程协作的核心机制condition_variable。主要内容包括： 问题背景：避免忙等待导致的CPU空转，需要等待/唤醒机制 解决方案：使用condition_variable配合mutex实现线程间高效协作 核心机制：wait()会自动释放锁并进入等待，notify_one()唤醒线程重新获取锁并检查条件 关键点：必须释放锁避免死锁、lambda只做条件判断、先修改条件再通知 与Java对比：C++
2026-03-30 00:15:13
1062
8方向控制圆盘-android
2025-10-30
Android Dsbridge （前端Vue3.0打包）
2025-10-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人