前言

前一段时间参与定位Tomcat某一问题，涉及到sendfile系统调用。忽然想到之前一些使用经验，知道Java领域中有不少开源软件，都使用零拷贝来提升期性能，于是有了本文。先看看我们这些耳熟能详的软件吧，你是否有了解过他们背后使用的技术点：

• Tomcat: 使用sendfile直接把大文件写入Socket，提升静态文件高效的数据传输
• Netty: 统一的ByteBuf机制，通过DirectBuffer封装，使用堆外内存进行Socket读写；也提供使用Sendfile来把文件缓冲区的数据发送到目标Channel
• RecketMQ：基于mmap内存映射文件方式对CommitLog文件读写文件，当客户端消费消息时直接把内容写到目标Socket

本文是对网上知识的收集与整理，以便分享给大家。本文中【OS层章节】中介绍零拷贝技术的部分内容与图片来源于看过就懂的java零拷贝及实现方式详解，在此先致谢。

前言

前一段时间看某一老产品的代码，是C/C++混合编写的代码，代码中充满了全局变量，并采用extern引用外部全局变量。问题是由于类与类之间存在依赖关系，如果都通过构造方法传入依赖，会导致整个对象依赖图构造复杂。对于上了年头的老代码，采用全局变量+extern引用能够简单粗暴地插入要新增的调用关系，但也带来了代码上腐化。

在我司新的C++融合编程规范中提到：

禁止通过声明的方式引用外部函数接口与变量。

只能通过包含头文件方式使用其它模块或文件提供的接口。通过声明的方式使用外部函数接口变量，容易在外部接口改变时可能导致声明有定义不一致。同时这种隐式依赖，容易导致架构腐化。

避免使用全局变量(节选)。

使用全局变量会导致业务代码和全局变量之间产生数据耦合。在不同编译单元的全局变量以及全局常量的初始化顺序没有被严格定义，使用时需要注意他们的初始化是否有相互依赖。

一个完整的应用是由一组相互协作的对象组成，开发人员要关注如何使这些对象协作来完成所需功能，并且要低耦合、高聚合。如果有个框架出来帮我们来创建对象及管理这些对象之间的依赖关系，那我们只需要聚集于业务逻辑。作为同时写过Java代码的老兵，了解管理依赖是Spring的设计初衷之一。Java天然具有动态反射能力，为IoC框架实现提供了基础。但C++并没有反射能对类的自省，如何实现一个简单的IoC框架？

案例

在我司新的C++融合编程规范中，提到避免定义C风格的变参数函数：

为了避免类型错误，应当使用可变参数模板等其它的方式来代替va_arg可变参数。

规范中也给出了一个简单的示例，像我这种有使用过的经验感觉示例有点意犹未尽。去年年底我使用C++写一个小工具，其中就使用可变参数模板封装了一个日志接口，同时参考了Java slf4j日志用法，支持占位符。正好借这个代码的来温习与讲解一下可变参数模板，感受一下C++模板编程的魅力。

前言

追求软件产品竞争力的企业，都会追求研发效能极致。对研发效能提升的投资是非常有价值的，因为如果一个开发者每天节可以节省一小时，即使一个50人的开发团队，总体节省的数字是非常可观的。

研发效能提升不仅仅是要提供更好的编程规范，开发工具，快速获得的流水线等硬件，也要对开发者提供贴心的软服务。因为目前软件开发不再单体活动，是一群人协作完成。因而个体问题转变了成社会问题：大家如何高效地协同、沟通和互动，团队与环境如何对开发者的工作产生影响。

软件开发要以人为本，对软件开发者群体进行研究。比如开发者之间是如何建立关系，关系是如何的管理，如何让参与者都有意愿，聚集有价值的活动，产生更大的能量，最终开发出有竞争力的软件。

前言

在我的多篇博文中提到软件开发需要师傅带徒弟，如在谈到Commit活动中，师傅们应该积极利用Commit活动，通过对代码检视，发现问题，帮助软件能力提升，养成良好的工作习惯。再如在谈到软件传承时，提升明确建立了师徒关系，师傅在日常开发中，通过言传身教，传递对代码的价值取向，精益品质追求。

在敏捷软件开发方法中，也提到“结对编程”：两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。

结对编程的目的一方面是对软件质量的看护手段，另一方面则是让参与的程序员能够提升自身能力。程序员结对工作的时候，水平较低的一方会潜移默化地受水平略高的程序员影响，学到新的东西。而水平高的一方同样因为不断地把自己的想法说出来，过程中会整理与完善自己的思路，是一个相互促进的过程。

师徒结对就是通过传、帮、带，通过互助、互信、合作来促进团队的软件开发专业能力的提升。

前言

我司很多的软件产品生命周期非常长，甚至还有20年前开发的软件产品还在网上发挥重要价值。前一段时间参与某一开源软件的自维护，分析其软件发展历史，发现它第一个版本开发于1999年，2002年重构发布2.0版本，到现在已历经了20+年。它的版权与主要作者也几经变化，最后成为Apache的顶级项目。无论是商业软件还是开源软件，越是基础性的软件，其生命周期越长，需要长期维护，软件也不可能由一个人或者一个团队自始至终开发、维护，软件需要传承。

软件产品生命周期的80%时间可能是维护阶段，在大规模开发阶段会留下很多"资产"。如开发过程文档，像我司基于DBOX的文档管理方式，侧重于权限控制，而未考虑使用体验。每个版本每个阶段的文档不同的目录管理，几年下来积累的各种文档散落在各个目录，文档间割裂缺少连续性，无法维护和使用。如几十上百篇的各个需求设计文档，在后期的维护阶段也没有人愿意去看，并且能看懂，原因是与现有代码实现严重脱钩了，文档起不到期望的软件传承。

我们耳熟能详的2G，3G，4G等，通讯技术似乎每5到10年有代际，不断地演进发展。那纯软件技术是不是也有代际？有。软件有继承才有发展，如我们部门某一软件产品从部署形态来讲，从早期的单板嵌入式，到X86虚拟化，再到现在全容器CloudNative化。从支持协议来看从传统的7号信令接入，再到全网IP化。软件一直在随着技术的发展在演进，包括其技术架构，交付形态，功能构成等都在变化中。软件传承相比软件维护并是不要发展，而是顺势而为，持续可交付与迭代。

今天趁着元旦有点时间，瞎聊糊侃一番软件传承，软件的传承有其特殊性。

案例

C/C++把内存管理交给程序员，由于对象生命周期的长短不一，需要记住内存在真正不需要它的时候显示释放，让程序员承担很大的心智负担，不经意间就出现内存泄露。通常正常的业务流程是不会出现内存泄露的，因为跑用例时会挂上内存检测工具，但一些异常分支，用例难以覆盖的地方，是内存泄露的重灾区。若一旦出现，都难以定位。前一段时间走读某一老产品的代码，是C/C++混合代码，发现一些潜在内存泄露问题。

问题1，每个异常分支需要手动释放方法内申请的内存，代码脱敏如下：

pBuf1 = malloc(sizeof(XX1)); // 申请一块内存
if (cond1) { // 异常分支1
    free(pBuf1);
    return RET_ERROR;
}
// 省略其它代码
pBuf2 = malloc(sizeof(XX2)); // 申请另一块内存
if (cond2) { // 异常分支2
    free(pBuf1); // 每个分支，都要释放前面所有代码
    free(pBuf2);
    return RET_ERROR;
}
// 省略其它代码
ptr->buf1 = pBuf1;  // 把多块内存的指针赋值给结构体指针ptr的成员变量，ptr是出参，ptr内存以及它的成员指针内存释放是在其它地方
ptr->buf2 = pBuf2;
return RET_SUCCESS

背景

还是在国庆节前，与一位大学同学聊天，忽然聊到他公司自从引入一位印度主管之后，开始推广敏捷开发，言语中透露出对推行敏捷开发的反思。什么站立会议，Backlog墙，Burndown图，迭代回顾等，看似这些活动很美好，都是围绕提升团队生产率，让软件开发更"敏捷"，但事实上还不如他们以前没有这些活动更高效。一个小团队的Leader反而成了这些活动监工，搞这些活动有时甚至不如自己亲自把活干了产出来得快。每个人只完成自己的任务，没有人会记得是谁认领了什么任务，团队反而缺少了应有的协作。从迭代计划来看，也许只是时间上需要迭代的划分，难以做到每个迭代可独立交付特征。这或许所谓的只有其"皮"。

我也有同样的感觉，联想我司10年前左右也在大力推广敏捷，并结合我司软件开发的特点，又在原有基础上进行改造。我们似乎在推广一种实践时，很容易跟风或是一刀切，人家这样玩，我们不跟着搞，似乎就是落后生产力了。总之推广是成功的，我们的优秀实践总结总会解决了XXX痛点，效率又提升了XXX。不过现在已没人再来提敏捷开发，不断的实践最终也留下一些"精华"，如站立会议改成Espace晨会，按月迭代计划尽可能早的部件间联调，每个C版本的AAR总结等等。