Tony Bai » 学习

Go 的“简单”幻象：易于上手，难于精通

bigwhite — Fri, 07 Nov 2025 06:28:23 +0000

本文永久链接 – https://tonybai.com/2025/11/07/go-simple-illusion-easy-to-learn-hard-to-master

大家好，我是Tony Bai。

“Go 语言看起来如此简单，我的这种假设是错的吗？”

近日，一位刚接触 Go 几个月的新手在reddit golang论坛发出了这样一个真诚的提问。他感觉 Go “超级简单”，并好奇自己是否因为初学者的身份，而忽略了语言中那些“疯狂的复杂性”。

这个问题，立刻引发了社区关注。数百条评论从四面八方涌来，汇成了一场关于 Go 语言简单性本质的深度辩论。最终，社区的集体智慧凝聚成一个经典而又充满辩证性的共识：Go 的简单，是刻意为之的设计；而通往精通之路，则隐藏在简约表象之下的深邃之处。

本文将带你深入探索这座“简单”的冰山，从其光彩照人的水上部分，一直潜入其复杂深邃的水下世界。

“蜜月期”——为什么 Go 语言感觉如此简单？

对于初学者而言，Go 带来的“简单”感受是真实且强烈的。这并非巧合，而是源于 Go 设计者们一系列深思熟虑的“减法”哲学。

极简的语法与关键字

“25 个关键字，宝贝！” 一位评论者这样感叹道。Go 有意地限制了语言的表面积，仅保留了构建大型系统所必需的核心元素。它只有一个循环结构 for，没有 while、do-while 或 foreach 的变体。这种极简主义，让学习者可以快速掌握语言的全貌，而不必记忆大量特殊语法。

“所见即所得”的代码

一位来自 Java/Python 背景的开发者分享道：“Go 给你的玩具可能更少，但至少你可以相信，它们不会在调试时反咬你一口。” Go 缺乏猴子补丁 (monkey patching)、复杂的继承体系和隐式的魔法，这意味着代码的行为更加可预测。“代码读起来就像它实际运行的样子，即便这意味着多写几行。”

“电池自带”的强大标准库

“标准库太棒了，” 社区普遍赞同，“你需要花些时间才能理解，在不引入单个依赖的情况下，你能做多少事情。” 从 HTTP 服务器到密码学工具，Go 的标准库提供了构建现代网络服务所需 90% 的功能，让初学者可以立即开始构建有价值的应用，而无需在茫茫的第三方库中选择和配置。

幻象的破灭——“简单”背后的隐藏复杂性

当“蜜月期”结束，开发者开始构建更复杂的真实世界系统时，Go 的另一面便会逐渐显现。这份复杂性，并非来自语言本身，而是源于 Go 为了维持简单性，而将复杂性“转移”到的地方。

并发：Go 的“光荣与荆棘”

这是社区中被提及次数最多的“深水区”。Go 通过 goroutine 和 channel，将并发编程的门槛降到了前所未有的低度。然而，这种易用性也隐藏着巨大的风险。

“理解并发作为一个概念可能会很复杂，但 Go 让实现它变得简单。”

但“实现简单”不等于“用对简单”。

Goroutine 泄露：新手很容易创建出无人“负责”的 goroutine，导致其在后台永久运行，悄无声息地消耗内存和 CPU。
竞态条件 (Race Conditions)：尽管 Go 提供了强大的竞态检测器 (-race)，但理解和避免数据竞争，需要对内存模型和同步原语（如 sync.Mutex）有深刻的理解。
Channel 的滥用：“我数不清有多少次，人们到处使用 goroutine 和 channel，然后好奇为什么他们的项目变得如此之慢。” Channel 是强大的工具，但错误地使用无缓冲 channel、忘记关闭 channel、或用它来解决本该用互斥锁解决的问题，都会导致死锁、性能下降和难以调试的 bug。

精通并发，是区分 Go 新手与专家的第一道分水岭。

运维复杂性

Go 的设计哲学，在某些方面将应用程序的韧性责任，从语言运行时“推”给了基础设施。这为 Go 程序带来了一种独特的运维复杂性。

最典型的例子就是 panic 的处理。

在某些语言中（如 Java），一个未捕获的异常通常只会导致单个线程死亡，而整个应用程序进程会默认继续运行。
但在 Go 中，一个未被 recover 的 panic 会导致整个程序（进程）立即崩溃退出。Go 语言本身不提供自动重启或进程守护的能力，它将这种“灾难恢复”的职责，明确地交给了程序的运行环境。

这意味着，构建一个高可用的 Go 服务，你必须依赖外部系统。正如一位资深开发者在讨论中指出的那样：

“像 panic 这样的东西，要求你在一个编排器（如 K8s/ECS 等）下运行你的生产系统。”

这种设计选择，对于新手来说可能是一个认知上的巨大跳跃。他们必须明白，Go 程序的健壮性，并不仅仅是代码层面的 if err != nil，更是在基础设施层面，通过配置进程管理器（如 systemd）或容器编排器（如 Kubernetes）的健康检查和自动重启策略来共同保证的。

Go 将自己定位为一个用于构建云原生应用的“零件”，而非一个大包大揽的“一体机”。这种对运维环境的隐性依赖，正是其简单性背后的一种深刻权衡。

“魔鬼在细节中”：切片、接口与错误处理

Go 的一些核心特性，虽然表面简单，但其底层机制却充满了需要深入理解的“微妙之处”。

切片 (Slices)：新手常常会对其“共享底层数组”的行为感到困惑，不经意间写出因 append 操作导致意外数据修改的 bug。
接口 (Interfaces)：nil 接口与“值为 nil 的接口”之间的区别，是无数 Gopher 都曾踩过的经典“坑”。
错误处理的冗长：if err != nil 虽然明确，但在 LLM 辅助编码时代到来之前，这种冗长曾是许多开发者的抱怨之源。现在，新的挑战变成了如何确保依赖 AI 的新手，能真正理解他们生成的每一行错误处理代码。

精通之路——从“知道”到“理解”

那么，如何跨越从“简单”到“精通”的鸿沟？社区的智慧为我们指明了方向。

接受 Go 的哲学

Go 是一门“刻意设计的简单语言”。它的目标，是让大型团队能够编写出风格统一、易于阅读和维护的代码。这意味着，你需要接受它的“冗长”，理解它为何抵制某些“高级”特性，并学会在其提供的“约束”下优雅地解决问题。

刻意练习核心概念

不要满足于 API 的表面用法。花时间去：

画图理解并发模式：亲自绘制 goroutine 如何通过 channel 通信，理解扇入 (fan-in)、扇出 (fan-out) 等模式。
实验切片的底层行为：编写小程序来观察 append 何时会触发底层数组的重新分配。
深入标准库源码：阅读 net/http 或 context 包的源码，是理解 Go 设计哲学的最佳途径。

拥抱“造轮子”

“你经常需要‘自己动手造轮子’(roll your own)”，一位开发者评论道。这在 Go 的世界里并非贬义。Go 强大的标准库为你提供了高质量的“零件”，鼓励你根据自己的具体需求，组合出最适合的“轮子”，而不是像其他生态那样，总是先去寻找一个庞大、臃肿的“现成汽车”。

小结：“简单”是起点，而非终点

回到最初的问题：Go 语言真的简单吗？

是的，Go 的入口极其简单。 它拥有平缓的学习曲线，让有经验的程序员可以在一周内上手，让新手也能在短时间内构建出有用的程序。

但精通 Go 绝不简单。 它的真正深度，不在于复杂的语法，而在于理解其并发模型背后的权衡、标准库设计的精妙、以及在简约哲学约束下构建复杂系统的工程智慧。

正如一位评论者所引用的那句古老格言：“一分钟学会，一辈子精通。” 虽说“一辈子”有些夸张，但这或许是对 Go 语言简单性与复杂性辩证关系的最佳诠释。Go 的“简单”，为你打开了一扇通往高效、可靠软件工程的大门，但门后的风景，需要你用持续的学习和深刻的思考，去亲自探索和领悟。

资料链接：https://www.reddit.com/r/golang/comments/1oj9jb6/golang_seems_so_simple_am_i_wrong_to_assume_that/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

Ubuntu Server 14.04安装docker

bigwhite — Fri, 26 Sep 2014 07:09:52 +0000

近期在研究docker这一轻量级容器引擎，研究docker对日常开发测试工作以及产品部署运维工作能带来哪些便利。前些时候刚刚将工作环境从 Ubuntu搬到了Mac Air上，对Mac OS X的一切均不甚熟悉，给docker研究带来了不便，于是打算在VirtualBox中安装一Ubuntu Server作为docker之承载平台。这里记录一下安装配置过程，主要为了备忘，如果能给其他人带来帮助，我会甚感欣慰。

docker官方对ubuntu的支持是蛮好的。docker对Linux内核版本有要求，要>=3.8，Ubuntu Server目前最新版本14.04.1恰符合这一要求，其kernel version = 3.13.0-32。

一、VirtualBox安装Ubuntu Server 14.04.1

VirtualBox安装Ubuntu OS做过了不止一遍，即便是换成最新的14.04.1 Server版，差别也没有太多，无非是按照安装提示，逐步Next。这里给Ubuntu Server 14.04分配了1G Memory, 32G动态硬盘空间。

【配置源】

默认情况下，/etc/apt/sources.list中只有一组源：cn.archive.ubuntu.com/ubuntu。这个国外源的下载速度显然无法满足我的要求，于是我把我常用的sohu源加入sources.list中，并且放在前面：

deb http://mirrors.sohu.com/ubuntu/ trusty main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-security main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted

deb-src http://mirros.sohu.com/ubuntu/ trusty main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-security main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted

公司采用代理访问外网，于是还得在/etc/apt/apt.conf中加上代理的设置，否则无法更新源，也就无法安装第三方软件：

Acquire::http::Proxy "http://username:passwd@proxyhost:proxyport";

【乱码处理】

由于安装时候选择了中国区域（locale zh_CN.UTF-8），因此在VirtualBox的窗口中直接执行命令的提示信息可能是乱码。对于Server，我们一般是不会直接通过其主机显示器登录使用的，都是通过终端访问，但在未安装和开启ssh服务和未配置端口转发前，我们只能先凑合这个窗口了。可先将/etc/default /locale中的LANGUAGE由"zh_CN:zh"改为"en_US:en"， logout后重新登录就可以看到非乱码的英文提示信息了。

【安装VirtualBox增强组件】

Ubuntu Server默认是不安装图形桌面的，只有一个命令行窗口，连鼠标都无法使用。因此增强组件安装的意义没有桌面系统那么强烈。我能想到的只有“共享目录”这一个功能有些用处。

安装方法也不难，按下面步骤逐步操作即可：

sudo apt-get install build-essential linux-headers-$(uname -r) dkms gcc g++
sudo mnt /dev/cdrom /mnt
cd /mnt
sudo bash ./VBoxLinuxAdditions.run

如果结果都是"done"，重启后就ok了。

【安装ssh服务】

    ssh服务由openssh-server提供：
    sudo apt-get openssh-server

   安装成功后，ssh server服务就会自动启动起来。

不过我们还是需要修改一些配置，比如允许Root登录：打开/etc/ssh/sshd_config，将PermitRootLogin后面的内容改为yes。

【设置端口转发】

前面说过，对于Server，我们更多是在其他主机上通过ssh或telnet远程访问该Server并执行各种操作。由于这里是VirtualBox安装的虚拟机，其他主机无法看到这台Server，我们需要设置端口转发将外部访问的数据转发给这个内部虚拟Server。

我们通过VirtualBox软件提供的图形界面即可完成这个操作：
    1、“设置”这个虚拟机
    2、在“网络”标签中，点击“端口转发”按钮，进入端口转发规则添加窗口。
    3、添加一条规则：
          名称：ssh-rules
          协议：TCP
          主机IP、子系统IP可以为空。
          主机端口：2222
          子系统端口：22
   4、配置结束

配置结束后，我们在宿主机上netstat -an|grep 2222，可以看到VirtualBox增加了该端口2222的监听。

现在我们就可以在其他机器上通过ssh -l tonybai 宿主机ip -p 2222的方式登录到我们新安装的这台虚拟Server了。

二、安装docker

docker目前的最新版本号是1.2.0，但14.04源中的docker还是正式稳定版1.0之前的版本，显然这是无法满足我的要求的。我们只能另外添加docker源来安装最新版docker。

【安装docker】

    我们在/etc/apt/sources.list中加入下面这个源：
       deb http://mirror.yandex.ru/mirrors/docker/ docker main

    执行apt-get update。

sudo apt-get install lxc-docker

正在读取软件包列表… 完成
正在分析软件包的依赖关系树
正在读取状态信息… 完成
将会安装下列额外的软件包：
aufs-tools cgroup-lite git git-man liberror-perl lxc-docker-1.2.0
建议安装的软件包：
git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk
gitweb git-arch git-bzr git-cvs git-mediawiki git-svn
下列新软件包将被安装：
aufs-tools cgroup-lite git git-man liberror-perl lxc-docker lxc-docker-1.2.0
升级了 0 个软件包，新安装了 7 个软件包，要卸载 0 个软件包，有 59 个软件包未被升级。
需要下载 7,477 kB 的软件包。
解压缩后会消耗掉 35.4 MB 的额外空间。
您希望继续执行吗？ [Y/n] y

这个源里的docker居然是最新版。于是安装之。安装后，我们执行docker version来确认一下安装是否成功。

tonybai@ubuntu-Server-14:~$ docker version
Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.1
Git commit (client): fa7b24f
OS/Arch (client): linux/amd64
2014/09/26 13:56:53 Get http:///var/run/docker.sock/v1.14/version: dial unix /var/run/docker.sock: permission denied

【为docker设置http代理】

在公司内使用代理才能访问到外网，于是我们也需要为docker命令设置代理以使其顺利执行命令。

我们安装的docker实际上分为两部分，docker命令行和docker daemon。两者是C/S结构，docker命令行将用户的请求转发给docker daemon，后者会真正与外部通信完成各种操作。

    于是我们可以这样为docker daemon设置http_proxy:
    sudo service docker stop
    sudo http_proxy='http://user:passwd@proxyhost:port' docker -d &

这样设置启动后，我们可以通过下面命令测试设置是否ok：

sudo docker search ubuntu

如果你看到下面信息，说明设置成功了：

    tonybai@ubuntu-Server-14:~$ sudo docker search ubuntu
[info] GET /v1.14/images/search?term=ubuntu
[b36518a9] +job search(ubuntu)
[b36518a9] -job search(ubuntu) = OK (0)
NAME                                             DESCRIPTION                                     STARS                                   OFFICIAL   AUTOMATED
ubuntu                                           Official Ubuntu base image                      709                                     [OK]
dockerfile/ubuntu                                Trusted automated Ubuntu (http://www.ubunt…   24                                                 [OK]
crashsystems/gitlab-docker                       A trusted, regularly updated build of GitL…   20                                                 [OK]
ubuntu-upstart                                   Upstart is an event-based replacement for …   13                                      [OK]
… ….

关于编程语言学习的一些体会

bigwhite — Tue, 22 Oct 2013 15:47:33 +0000

Learn at least one new language every year.
— Andy Hunt and Dave Thomas

自己一直是“每年学习一门新语言”的忠实拥趸，曾先后认真地学习了Haskell、Common Lisp、Python、Go等语言，对Prolog、Scala、Erlang、Lua、PHP也有一定了解。但几年下来，只有Python一门语言算是真正被留在我的大脑里，用在了工作中。其他那几门语言留下来的只是一些思想了。这似乎符合了Andy Hunt和Dave Thomas在《程序员修炼之道》中对于这一实践目的的阐述：“学会用多种方式解决问题，扩展我们的视野，避免思路僵化和停滞不前”^_^。

即便是残存的思想，其实也并不深刻。要真正会运用新思维并非那么简单。一门编程语言从入门到精通，至少要经历学语法、做实践、用idioms（写出地道的代码）三个阶段。这让我深刻的感悟到：不以使用为目的的语言学习，都是在浪费生命！

有精力多学习些语言自然很好，我迫切期待能拥有一个像“七龙珠”中孙悟空那样的“精神时光屋”呢。但现实中，人的精力是有限的，而我们要面对的计算机科学领域中的知识、技能以及问题却似乎是无限的。因此在“每年至少学习一门新语言”这一实践上，建议不要过于教条。从编程语言自身来看，范型(Paradigm)是影响语言思维差异的主要因素，而编程语言的范型有限，主流的也就那么几种：命令式（过程式）、函数式、逻辑式、面向对象等。每种范型的背后都有几种、十几种甚至几十种语言，我们其实没有必要都去学。从拓展视野的角度去说，从每种主流范式中找到一两门典型的语言去学习就可以了。比如命令式的，我们可以选择C；函数式我们选择Haskell；逻辑式的选择Prolog；面向对象的选择Java等。

即便是从每个范型中挑出一门，你要付出的精力依旧不少，我们还要考虑其实用性：要以使用为目的。如果能将其用在工作中，天天与你相伴，被他人接受，自然最好；退而求其次，你能找到一两个开源项目，并参与其中也是可以的，至少可以让你保持手热；如果这两点都无法做到，仅仅是凭借个人的热情与坚持，那是不会持久的，若干时间后，你就会对其生疏，可能连基本的"Hello World"语法都记不得了。不过这个年头，思想也不能不要。在有剩余精力的前提下，挑选些牛人们极力“鼓吹”的语言，吸收一下其思想精华，说不定哪天就能用得上，让自己和大家都感觉你很NB，抬高一下自己的身价^_^。记住：编程语言也是要拼爹的，系出名门的语言(诸如Go、Dart等)自然得到更多的青睐、使用和推广，出位的几率也就高出许多，尤其是在目前新编程语言百花齐放的阶段。因此在选择有思想的新语言时，最好在这些名门之后中做优选。

这个时代喜欢“专家”，因此我们在一两门语言上务必要做到“精专”，这是会给你带来黄油和面包的语言。要专到什么程度呢？我有一个同事，什么问题都用C解决。他甚至为此写了个不小的基础框架，所有业务问题的Code放在框架中被回调即可，即便是这个问题用Python实现只需几行代码。

计算机科学的研究核心是什么？我想肯定不是编程语言，就好比社会科学研究的核心不是人类语言一样。我比较欣赏这样的观点：作为程序员而言，最重要的是去创造，而不是研究。我们应更多的利用已经掌握的语言解决现实中的问题。做编程语言研究的人可能要了解各种语言的特点与实现方式，但对于大多数的程序员来说，其实我们只需要关注问题域：做底层平台开发的，关注机器模型、通信原理以及OS原理和实现细节；做算法的，很荣幸，那才是正统的程序设计的核心；前端攻城师则更多关注用户的体验。而在这些解决实际问题的过程中，我们更多采用的是“制式”的编程语言。即做平台开发的，一般用C，C++等系统编程语言，更多的考虑的是性能；做前端开发的，PHP/JavaScript不可或缺。我们要考虑的是如何利用这些制式的编程语言去解决问题，而在这些制式语言上，我们要做到精通。

从新兴语言中借鉴新思想，然后在旧语言中实现新语言的特性，其实更多是在旧语言中实现了某种语法糖，你爱吃，不代表其他人也理解也爱吃，还容易被人误认为是“炫技”。如果你是技术负责人，且经过评估，新语言十分适合这个问题域，那莫不入直接引入这门语言，让大家都能使用到这门语言的新思想、新特性。

辩证的说，任何一种编程语言都有其利与弊，比如Haskell，纯函数式语言，变量不能改变，无状态，对并行处理具有天然的适应性，但在处理基本IO时却要编写难于理解的monad；而在命令式语言中，这种IO处理简直简单的不得了。

关于函数式语言，个人感觉未来若干年内仍难以大行其道，建议还是跟上命令式语言的演化主线吧。

跨越问题域学习语言，通常收获不大。一个做平台服务端，用惯了C的资深程序员，让他去学PHP写前端代码，估计是无法迸发出任何火花的。

以上是自己这些年关于编程语言学习的一些体会，比较零散，但希望能有帮助。

利用ZooKeeper服务实现分布式系统的配置数据同步

bigwhite — Wed, 28 Aug 2013 11:32:14 +0000

很多时候，一旦习惯了某些事情，也就习惯了它们的恶劣，习惯了它们的丑陋，习惯了它们“赋予”你的各种痛苦。
– Tony Bai

一、痼疾难解

曾几何时，在那个还没有集群化，没有分布式的时代，它还是一个不错的方案，至少在线上没有暴露出太多问题，它也不在我们关注的重点范围之内。但随着集群化、分布式的新版本的到来，那一大坨遗留的代码就变得格外让人不顺眼，同时问题也随之在线上暴露开来了。

这里的“它”指的就是我们目前的业务配置数据同步方案。简单描述这个方案如下：

* 方案涉及两个角色 – 数据库(DB)与应用节点（app_node)；
* 所有的业务配置数据均统一存储在DB中；
* 应用节点在启动后从DB中读取最新业务配置数据；
* 应用节点运行过程中，如果DB中的业务配置数据发生变更（增/删/改），DB中的触发器(trigger)将会执行。在触发器的脚本中，触发器将会【串行】地与每个应用节点建立TCP链接，并将业务配置表的变更信息发给各个应用节点。应用节点会接收并【解析】触发器发过来变更数据包，并同步到自己的本地内存中。这样就达到了运行时更新配置的目的。

上面我用【】标记了两个关键词：“串行”和“解析”。这两个词隐含有这个方案的两个主要问题。

“串行” – 意味着每一次DB的业务配置数据变更，trigger脚本都要逐个与应用节点建立链接并收发数据。当应用节点逐渐增多时，每一次业务数据同步都会相当地耗时。尤其是当某个应用节点所在主机出现问题时，到该节点链接建立的过程会阻塞，导致整个业务配置数据同步的时间达到无法忍受的地步。

“解析” – 我们自定义了trigger与应用节点之间的协议包。协议包中包含了每次变更的详细信息，比如在某个表添加一条记录，trigger会将这个记录的每个字段信息排成一行打包发给应用节点。应用节点收到这个包后，会根据已有的表字段信息对该包进行解析。看得出这是一个很强的耦合：表字段一旦修改，trigger脚本要修改，应用节点的解析函数要修改，还要考虑协议包中表字段的排序。如果应用节点解析时与trigger脚本打包时的字段顺序不同的话，那就可能出现严重错误，而且这种错误有时难于校验并难于发现。

二、曾经的努力

针对这个方案的不足，我们曾经也做过改进，但主要针对的是解决“串行”这个问题上。

第一次改进：同步的发起能否并行做？trigger脚本能否并行发起对各个应用节点的链接建立请求？

Java组同事对trigger脚本做了改进。让trigger脚本调用function，而function中又调用了写好的Java方法，Java代码由DB加载到环境中。在Java方法中创建多个同步线程，并发与各应用节点建立链接并发送数据。这个方法的确可以变“串行”为 “并行”，但不知为何生产环境中实际运行时偶尔会出现异常，该异常发生在DB中，影响很大。有时还会导致DB的一些异常现象。至今原因尚未明确，我们无奈退回到以前的方案。

第二次改进：从Push模式到Pull模式

在之前部门新规划的一个产品中，开发人员对数据同步的机制做了重新的设计，将原来的Push模式改为了Pull模式。大致方案是：

    * 业务数据变更时，trigger直接将变更内容（以老方案中那个协议包的打包格式）写到一个“变更日志表”中，每条记录有一个唯一的序号，序号递增。
    * 应用节点启动后，从DB加载最新配置信息，查询“变更日志表”，得到该表内最新的一条记录的序号n。
    * 应用节点以“轮询”的方式定期查询“变更日志表”，并读取和解析那些序号比序号n更新的记录；更新完后，将继续保存最新的一条记录序号。
    * 数据库中有job定期对“变更日志表”中的记录进行过期删除处理。

个人感觉第二个方案应该是理想方案的一个雏形，虽然目前它的同步更新可能不是那么及时，与DB交互过多（方案细节中每个应用节点在处理完一条记录后还要更新记录的状态）。该方案设计者也完全也可以放弃那个导致耦合的协议包设计，但他最终还是选择保留了原有协议包解析函数。目前该方案在产品环境下运行还算良好，并未暴露出什么问题。这算是一次有效的改进，也为本文中要提到的方案提供了一些思路启示。

三、与时俱进

ZooKeeper生来就具备解决分布式系统的配置分发和同步的能力。利用ZooKeeper服务实现分布式系统的统一配置中心已经不是那么新鲜的话题了。最简单的模型莫过于将配置数据存储在ZooKeeper上的路径节点上，然后应用节点在这些配置节点上添加watch。当配置数据变更时，每个应用节点都可以及时得到通知，同步到最新数据。这种模型对于一些量少简单的系统配置来说较为合适。对于我们每个表动辄上万条配置的情形似乎不那么适合，想象一下每个应用节点要添加上万个watch，这对ZooKeeper而言也是压力山大啊。因此用ZooKeeper提供的诸多服务如何来优化我们上面提到的两个主要问题呢？这里提出一种方案仅供参考。

方案示意图：

DB —-> Config Center Services(css_agent + ZooKeeper) —> App Node

在新方案中，我们要：
    保留 – 保留trigger脚本，作为业务数据变更的唯一的触发起点；
    摒弃 – 摒弃那个复杂的带来耦合的协议格式；
    借鉴 – 借鉴“Push -> Pull”的数据获取方式。

新方案中除了DB、应用节点(app_node)外，新增加了一个角色Config Center Services(缩写为ccs），ccs由ZooKeeper + ccs_agent的集群组成。简单起见，每个ZooKeeper节点上部署一个ccs_agent。这些角色之间的数据流和指令流关系，即该方案的原理如下：

    * 初始化
        – ZooKeeper集群启动；
        – ccs_agent启动，利用ZooKeeper提供的leader election服务，选出ccs_agent leader。ccs_agent leader启动后负责在ZooKeeper中建立业务配置表node，比如：表employee_info_tab对应的node路径为“/ccs /foo_app/employee_info_tab”；
        – ccs_agent启动后会监听一个端口，用来接受DB trigger向其发起的数据链接；
      – 应用节点启动，监听ZooKeeper上所有（数量有限的）业务配置表node的child event；

    * 数据变更
        – DB中某业务表比如employee_info_tab增加了一条id为"1234567"的记录；
        – 触发器启动，向ccs_agent cluster中任意一个可用的节点建立链接，并将数据包“^employee_info_tab|ADD|1234567$"发送给 ccs_agent；
        – ccs_agent收取并解析trigger发来的数据包，在对应的/ccs/foo_app/employee_info_tab下建立ZOO_SEQUENCE类型节点“item-000000000”，该节点的值为“ADD 1234567"；
        – ZooKeeper将/ccs/foo_app/employee_info_tab节点的child事件发给所有watch该节点事件的应用节点；
        – 应用节点“取出”/ccs/foo_app/employee_info_tab节点下的children节点"item-000000000"，并读取其值，后续到DB的employee_info_tab中将id = 1234567的这条记录select出来，将该条记录更新到本地内存中。应用节点记录下处理过的当下节点id为"item-000000000"；
        – DB业务表employee_info_tab又增加了两条记录，id分别为"7777777"和"8888888"，经过上面描述的流程，/ccs /foo_app/employee_info_tab节点下会增加"item-000000001"和"item-000000002"两项；应用节点最终会收到child事件通知。应用节点“取出”/ccs/foo_app/employee_info_tab节点下的所有 children节点并排序。之后，处理那些id号大于"item-000000000"的节点，并将当前节点id记录为“item- 000000002"。依次类推。

* 过期处理
– ccs_agent leader负责定期扫描ZooKeeper中/ccs下各个表节点下的子项，对于超出过期时间的item进行删除处理。

    * 应用节点重启
        - 应用节点重启后，会首先从db读取最新信息，并记录启动时间戳；
- 应用节点重启后，在收到zookeeper的数据变更事件后，会根据当前时间戳与变更表节点下的item创建时间进行比较，并仅处理比启动时间戳新的 item的数据。

这个方案主要利用了ZooKeeper提供的leader election服务以及sequence节点的特性，几点好处在于：

    – 串行通知变为并行通知，且通知到达及时；
    – 变更数据的Push模式为Pull模式，降低了或去除了诸多耦合，包括：
            1) 去除trigger脚本与表字段及字段顺序的耦合；
            2) 去除应用节点与表字段顺序的耦合；
            3) 降低应用节点与表字段构成的耦合。
    – 应用节点无需复杂的包解析，简化后期维护。

当然为了该方案新增若干网元会给产品部署和维护带来一些复杂性，这算是不足之处吧。

四、Demo

这里有一个600多行代码的Demo，模拟新方案中几个角色：
    DB – trigger_sim.py
    应用节点 – app.c
    ccs_agent – ccs_agent.c

模拟的步骤大致如下（单机版）：

a) 启动ZooKeeper
    $> zkServer.sh start
    JMX enabled by default
    Using config: /home1/tonybai/.bin/zookeeper-3.4.5/bin/../conf/zoo.cfg
    Starting zookeeper … STARTED

b) 启动ccs_agent
    $> ccs_agent
    This is [ccs-member0000000037], i am a leader
    /ccs node exists
    /ccs/employee_info_tab node exists
    /ccs/boss_info_tab node exists
    trigger listen thread start up!
    item expire thread start up!

c) 启动app

d) 使用trigger_sim.py模拟DB触发trigger
$> trigger_sim.py employee_info_tab ADD 1234567

可以看到ccs_agent输出结果如下：
table[employee_info_tab], oper_type[ADD], id[1234567]

app的输出如下：
    child event happened: type[4]
    item-0000000015
    employee_info_tab: execute [ADD 1234567]

大约30s后，ccs_agent会输出如下：
[expire]: employee_info_tab: expire [item-0000000015]

模拟步骤在README里有写。这里仅是Demo代码，存在硬编码以及异常处理考虑不全面的情况，不要拍砖哦。

利用ZooKeeper服务实现分布式系统的Leader选举

bigwhite — Fri, 23 Aug 2013 14:31:02 +0000

每次与Java组的同事们坐下来谈技术、谈理想、谈人生时，Java组的同事总会向我们投来羡慕的眼光：卧槽！又是自己开发的工具，太NB了。这时C程序员们的脸上就会洋溢出自豪的笑容，然后内心骂道：谁让我们没有现成的呢。另一个空间里的某些“无C不欢”们或者某些“C Guru”们会骂道：靠，有了也不用，自己写！

有时候，C程序员真的有一种下意识：不情愿使用其他语言开发的工具、框架或服务，且比其他程序员更爱“重新发明轮子”（有利有弊）。也许这是某种骨子里的自负在搞怪；另外一个极端：今天和我聊天的一个经验丰富的C程序员还在忧虑：如果离职是否有公司会要他:(。

其实这个时代的C程序员一直活得挺纠结^_^。

这个世界，软硬件发展日新月异，越来越多的后端程序用Java等其他语言实现。Java高级选手在这个世界上也甚是吃香，这个你看看各大招聘网站就知道了。再听听坊间“BAT”三巨头给出的高高在上的offer价格，也可以看出Java程序员是多么的有“钱途”和受欢迎了。当然拿好offer的前提是你的Java底子不薄。

其实无论用什么编程语言，成为牛人后，钱途也都是杠杠的。

没有什么好的开场白，于是有了上面一些“胡言乱语”。我们言归正传。

本文是一篇初级技术博文。讲的是如何使用ZooKeeper C API通过ZooKeeper的服务实现分布式系统的Leader选举。当然这一试验是为了尝试解决我们自己的分布式系统在集中配置数据分发这一环节上的一个“固疾”。还好我还不那么纠结，也没有重新实现ZooKeeper的冲动，于是我就用了ZooKeeper这一Java实现的成熟的分布式系统的服务框架。

* 搭建ZooKeeper服务环境

– 下载官方stable release版本 – ZooKeeper3.4.5。解压后，将$ZooKeeper_INSTALL_PATH/bin加入到PATH变量中（其中ZooKeeper_INSTALL_PATH为解压后ZooKeeper-3.4.5目录的绝对路径）。

– 试验环境下，最简单的ZooKeeper用法就是使用单机版。
进入到$ZooKeeper_INSTALL_PATH/conf下，将zoo_sample.cfg改名为zoo.cfg，即可作为单机版ZooKeeper的配置文件。当然你也可以像我一样随意修改修改：

    # The number of milliseconds of each tick
   tickTime=2000
   # The number of ticks that the initial
   # synchronization phase can take
   initLimit=5
   # The number of ticks that can pass between
   # sending a request and getting an acknowledgement
   syncLimit=2

   dataDir=/home/tonybai/proj/myZooKeeper
   # the port at which the clients will connect
   clientPort=2181

      如果你要体验多机版ZooKeeper服务，那你还要继续动动手脚，以双机版为例，假设有两个ZooKeeper节点(10.0.0.13和10.0.0.14)：

10.0.0.13上的ZooKeeper节点1的配置文件如下：

   dataDir=/home/tonybai/proj/myZooKeeper
   # the port at which the clients will connect
   clientPort=2181

server.1=10.0.0.13:2888:3888
server.2=10.0.0.14:2888:3888

10.0.0.14上的ZooKeeper节点2的配置文件如下：

   dataDir=/home/tonybai/proj/myZooKeeper
   # the port at which the clients will connect
   clientPort=2181

server.1=10.0.0.13:2888:3888
server.2=10.0.0.14:2888:3888

      别忘了在每个节点的dataDir下分别创建一个myid文件：
    在10.0.0.13节点1上执行：

     $> echo 1 > myid

      在10.0.0.14节点2上执行：

   $> echo 2 > myid

启动ZooKeeper执行：
$> zkServer.sh start

模拟一个客户端连到ZooKeeper服务上：
$> zkCli.sh

    成功链接后，你将进入一个命令行交互界面：
       [zk: 10.0.0.13:2181(CONNECTED) 1] help
    ZooKeeper -server host:port cmd args
    connect host:port
    get path [watch]
    ls path [watch]
    set path data [version]
    rmr path
    delquota [-n|-b] path
        … …

* 选主原理

ZooKeeper在选主过程中提供的服务就好比一栋名为"/election"小屋，小屋只有一个门，各节点只能通过这个门逐个进入。每个节点进入后，都会被分配唯一编号(member-n)，编号n自小到大递增，节点编号最小的自封为Leader，其他节点只能做跟班的（follower) – 这年头还是小的吃香：原配干不过小三儿，小三儿干不过小四儿，不是么^_^！）。
每当一个节点离开，ZooKeeper都会通知屋内的所有节点，屋内节点收到通知后再次判断一下自己是否是屋内剩余节点中编号最小的节点，如果是，则自封为Leader，否则为Follower。

再用稍正式的语言重述一遍：

各个子节点同时在某个ZooKeeper数据路径/election下建立"ZOO_SEQUENCE|ZOO_EPHEMERAL"节点 – member，且各个节点监视(Watch) /election路径的子路径的变更事件。ZooKeeper的sequence节点特性保证节点创建时会被从小到大加上编号。同时节点的 ephemeral特性保证一旦子节点宕机或异常停掉，其对应的member节点会被ZooKeeper自动删除，而其他节点会收到该变更通知，重新判定自己是leader还是follower以及谁才是真正的leader。

* 示例代码

关于ZooKeeper的C API的使用资料甚少，但这里就偏偏要用C API举例。

C API的安装方法：进入$ZOOKEEPER_INSTALL_PATH/src/c下面，configure->make->make install即可。

ZooKeeper的C API分为同步与异步两种模式，这里简单起见用的都是同步机制。代码不多，索性全贴出来。在这里能checkout到全部代码。

/* election.c */
#include
#include
#include
#include
#include "zookeeper.h"

static int
is_leader(zhandle_t* zkhandle, char *myid);

static void
get_node_name(const char *buf, char *node);

struct watch_func_para_t {
zhandle_t *zkhandle;
char node[64];
};

void
election_children_watcher(zhandle_t* zh, int type, int state,
const char* path, void* watcherCtx)
{
int ret = 0;

struct watch_func_para_t* para= (struct watch_func_para_t*)watcherCtx;

struct String_vector strings;
struct Stat stat;

    /* 重新监听 */
    ret = zoo_wget_children2(para->zkhandle, "/election", election_children_watcher,
                             watcherCtx, &strings, &stat);
    if (ret) {
        fprintf(stderr, "child: zoo_wget_children2 error [%d]\n", ret);
        exit(EXIT_FAILURE);
    }

    /* 判断主从 */
    if (is_leader(para->zkhandle, para->node))
        printf("This is [%s], i am a leader\n", para->node);
    else
        printf("This is [%s], i am a follower\n", para->node);

return;
}

void def_election_watcher(zhandle_t* zh, int type, int state,
        const char* path, void* watcherCtx)
{
    printf("Something happened.\n");
    printf("type: %d\n", type);
    printf("state: %d\n", state);
    printf("path: %s\n", path);
    printf("watcherCtx: %s\n", (char *)watcherCtx);
}

int
main(int argc, const char *argv[])
{

    const char* host = "10.0.0.13:2181";
    zhandle_t* zkhandle;
    int timeout = 5000;
    char buf[512] = {0};
    char node[512] = {0};

    zoo_set_debug_level(ZOO_LOG_LEVEL_WARN);
    zkhandle = zookeeper_init(host, def_election_watcher, timeout,
                              0, "Zookeeper examples: election", 0);
    if (zkhandle == NULL) {
        fprintf(stderr, "Connecting to zookeeper servers error…\n");
        exit(EXIT_FAILURE);
    }

    /* 在/election下创建member节点 */
    int ret = zoo_create(zkhandle,
                        "/election/member",
                        "hello",
                        5,
                        &ZOO_OPEN_ACL_UNSAFE, /* a completely open ACL */
                        ZOO_SEQUENCE|ZOO_EPHEMERAL,
                        buf,
                        sizeof(buf)-1);
    if (ret) {
        fprintf(stderr, "zoo_create error [%d]\n", ret);
        exit(EXIT_FAILURE);
    }

    get_node_name(buf, node);
    /* 判断当前是否是Leader节点 */
    if (is_leader(zkhandle, node)) {
        printf("This is [%s], i am a leader\n", node);
    } else {
        printf("This is [%s], i am a follower\n", node);
    }

    struct Stat stat;
    struct String_vector strings;
    struct watch_func_para_t para;
    memset(¶, 0, sizeof(para));
    para.zkhandle = zkhandle;
    strcpy(para.node, node);

    /* 监视/election的所有子节点事件 */
    ret = zoo_wget_children2(zkhandle, "/election", election_children_watcher, ¶, &strings, &stat);
    if (ret) {
        fprintf(stderr, "zoo_wget_children2 error [%d]\n", ret);
        exit(EXIT_FAILURE);
    }

/* just wait for experiments*/
sleep(10000);

zookeeper_close(zkhandle);
}

static int
is_leader( zhandle_t* zkhandle, char *myid)
{
int ret = 0;
int flag = 1;

    struct String_vector strings;
    ret = zoo_get_children(zkhandle, "/election", 0, &strings);
    if (ret) {
        fprintf(stderr, "Error %d for %s\n", ret, "get_children");
        exit(EXIT_FAILURE);
    }

    /* 计数 */
    for (int i = 0; i < strings.count; i++) {
        if (strcmp(myid, strings.data[i]) > 0) {
            flag = 0;
            break;
        }
    }

return flag;
}

static void
get_node_name(const char *buf, char *node)
{
    const char *p = buf;
    int i;
    for (i = strlen(buf) – 1; i >= 0; i–) {
        if (*(p + i) == '/') {
            break;
        }
    }

strcpy(node, p + i + 1);
return;
}

编译这个代码：
$> gcc -g -std=gnu99 -o election election.c -DTHREADED -I/usr/local/include/zookeeper -lzookeeper_mt -lpthread

验证时，我们在不同窗口启动三次election程序：

窗口1， election启动：

$> election
Something happened.
type: -1
state: 3
path:
watcherCtx: Zookeeper examples: election
This is [member0000000001], i am a leader

窗口2，election启动：

$> election
Something happened.
type: -1
state: 3
path:
watcherCtx: Zookeeper examples: election
This is [member0000000002], i am a follower

此时窗口1中的election也会收到/election的字节点增加事件，并给出响应：

This is [member0000000001], i am a leader

同理当窗口3中的election启动时，窗口1和2中的election都能收到变动通知，并给予响应。

我们现在停掉窗口1中的election，大约5s后，我们在窗口2中看到：

This is [member0000000002], i am a leader

在窗口3中看到：

This is [member0000000003], i am a follower

可以看出窗口2和3中的election程序又做了一次自我选举。结果窗口2中的election由于节点编号最小而被选为Leader。

也谈代码行统计

bigwhite — Wed, 24 Jul 2013 10:12:50 +0000

一直在纠结要不要就这个话题写点什么，之前梳理过一些思路，但感觉这个题目似乎没什么大意义。不过将东西憋在肚子里的滋味总是不好受的，最终我还是选择写出来一些，即便它真的没有什么意义^_^。

事情缘于近期领导让我负责的一个内部任务：制定组织内的代码行统计标准并实现标准化的工具。就是这个任务促使了我对代码行统计重新做了一番考量。

对代码行统计的理解

代码行统计这个活动不是软件开发过程中的关键路径活动，它对代码质量、开发进度以及软件价格几乎产生不了什么影响，应该算是个可有可无的东西。

就代码行统计这个活动本身而言，我个人的观点是没有代码行统计不表明不能开发出好软件；有了代码行统计，就一定能开发出高质量软件吗？

不过有一种观点认为：世界的本质是数据。通过数据我们可以发现事物运行的规律。代码行统计则是软件工程中对“数据”要求的产物。过程的好坏需要有数据支撑，因此代码行统计这个活动成为了人们实现“用数据说话”的一柄利器。在“数据为王”的今天，我们无论如何都不能忽视数据的作用。人们通过数据来反映软件开发过程中的一些规律性的东西本身也没有什么不妥。另外代码是软件开发过程的最重要成果物，因此围绕着代码的性态，我们用工具做诸多分析，期望从得到的数据中找寻出一些可以指导和改善我们后续工作的蛛丝马迹。代码行统计提供的多是基础数据，在与其他过程基础数据结合分析后，我们能得到更多的信息。

合理地使用场合

个人觉得下面几个场合对代码行统计的需求是合理的：

* 统计代码总规模
某个项目、某个模块或又某个版本的代码总规模。

* 代码“成分”统计
统计空行、注释、代码的行数及占比、重复代码行数及占比等。

* 版本间代码变更差异统计
两个有关联版本的数据对比统计，获取版本间的有效变更数据情况并作为基础数据提供给后续分析。

一些过程质量指标，诸如千行代码缺陷率等均是以上面这些代码行统计输出的基础数据为基础的。

“误用”

有合理的使用，就有“不合理”的使用 – “误用”。之所以加上引号，是因为至今人们对此见仁见智，尚无定论。以下列举两典型的“误用”。

* 通过代码行统计评估进度

有些组织在项目开始初期，就对成果的规模做了估计，比如10w行代码。然后在过程中使用代码统计工具对项目当前已实现的规模进行统计，并用统计出的数据与初值的比值作为项目进度的评估参考。个人认为这是种典型的误用。盖茨说过：“用代码行数来衡量编程的进度，就如同用航空器零件的重量来衡量航空飞机的制造进度一样”。且不提初期的估值有多么的不准确，就代码的行数本身而言，也受到各种因素的影响，比如设计方案、实现者的功力以及编码习惯等。同一个功能，A 实现需要100行代码；换成B就需要10行。

* 通过代码行统计评估程序员绩效

在一些外包公司或外包项目里，尤其是日本人的外包项目里，通过编写代码行的多少来评估程序员绩效的作法是很有市场的。我不能完全否定这种方法的正确性，因为在日本外包项目中变态的日本人对代码的审核极其严格，并且有着苛刻的编码标准和风格，因此一些胡乱堆砌代码或使用奇技淫巧的代码都会被驳回，因此所有项目开发者的效率似乎被约束到了一个平均线上。在这个前提下，产出的代码越多，似乎的确表明了这个开发者超出了平均效率，或至少牺牲了不少个人时间来完成项目中的任务，精神可嘉，绩效被评高似乎也是合情合理的。但除此之外，用代码行多寡来评估程序员绩效显然是不受待见的。

考虑这个“误用”时，我也想模仿盖茨的话做个形象且深刻比喻，最初我写下的是这句话：“用代码行数多少来评估程序员的绩效，就好比用曲子的长短来评估音乐家的水平，或又好比用画幅的大小来衡量画家的水准，或又好比用电影的时长来掂量导演的功力！”。但仔细揣摩后发现这句话看起来挺像那么回事，但实际上却是不恰当的。什么是水准、水平或功力，这是衡量人的水平高低的；而绩效则是一段时间范畴内工作成果的评估；一个是长期的肯定，一个是阶段性的成绩。我显然是将水平和绩效(阶段性成绩)混为一谈了。高水平的开发者不一定每个周期都会取得高绩效，低水平的开发者也不是无法取得高绩效的。因此这句话似乎应该改成：“用代码行数多少来评估程序员的绩效，就好比用这首曲子的长短来评估音乐家在这个阶段的水平，或又好比用画幅的大小来衡量画家的这个阶段水准，或又好比用电影的时长来掂量导演在这部电影上的功力！”。是不是读起来很别扭啊，反正我是这么觉得的。程序员的成果物是代码，代码好坏优劣对程序员绩效有着直接影响（虽非充分必要条件），我们不妨替换一下本体来换种说法：“用代码行数多少来评估代码实现的好坏，就好比用曲子的长短来评估曲子的优劣，或又好比用画幅的大小来衡量画作的高低，或又好比用电影的时长来掂量影片的良莠”！

对用代码行数多少来评估程序员绩效这种事情，我是很反感的，但在国内许多公司里，这种现象却又屡见不鲜。但这种行为背后的动机何在呢？传统工厂中，衡量一个worker的绩效是相对容易量化，也比较客观的，比如制鞋厂可以用制成鞋子的数量来确定 worker绩效；在汽车组装车间，组装汽车的数量可以作为作为工人们的绩效；在炼钢厂，班组炼出的钢铁的吨数可作为班组成员绩效等等。将代码行数作为程序员绩效的参考指标也许是一个无奈的方法。之所以想用代码行数，是因为程序员工作中能量化的东西不多，代码行数首当其冲。组织为了尽量减少绩效评定时主观的成分，增加客观的评价，代码行统计从此被误用了。

代码行统计的高效使用

* 标准统一，工具一致

代码行统计工具有很多，因此执行这个活动时会出现不同人使用的代码行统计工具不一致的情况；并且不同工具对一些指标的定义也许有不同，这会导致收集到的数据存在含义不一致，精确度差的问题。因此高效使用代码行统计工具的一个前提就是（统计）标准统一，工具一致。

* 零干扰

一些传统的代码行统计方法是配置负责人收到统计任务时，将任务分发给各个模块的负责人，由各个模块负责人各自统计，然后反馈给配置负责人汇总。这种方式显然不那么高效，而且容易引起一些对统计任务的反感情绪。高效的代码行统计最好能做到对开发人员“零干扰”。配置负责人可以通过“自动化”的静默方式收集代码行数据。当然这需要对一些现成的开源工具做一些包装或二次开发才能做到，个人觉得这种投入是值得的，同时也能避免标准不一，工具不一致的情况。

Python脚本命令行变量的实现

bigwhite — Tue, 09 Jul 2013 07:33:34 +0000

我们知道Make工具是支持命令行变量的，这种手段为我们提供了很好的灵活性，我们可以通过敲入不同的命令行参数来决定Makefile脚本的行为。

make [variable1=value1 variable2=value2 ... ... ]。

#
# Makefile
#

CMODE = 64-bit

ifeq ($(CMODE), 64-bit)
    CFLAGS += -m64
endif

all:
    gcc $(CFLAGS) -o foo foo.c

$> make
gcc -m64 -o foo foo.c

$> make CMODE=32-bit
gcc -o foo foo.c

近期我们的一个Python脚本工具也有类似的需求了，但Python脚本原生并不支持这种命令行变量，我们来看看是否可以利用Python提供的机制实现一种可以满足我们需求的命令行变量。

我们的期望结果如下：

$> foo.py fruit=apple

# foo.py

flag = '' #这个定义可以有，也可以没有，如果有，可以理解为默认值

….

if flag == 'apple':
    ….
elif flag == 'orange':
    ….
elif flag == 'banana':
    ….
else:
    ….

Python是动态语言，提供了注入eval、exec等在运行时执行代码的能力。我们要实现命令行变量的机制，离不开这些能力的支持。eval用于求值表达式，而x=y是语句，我们只能用exec。

【#1】

import sys

if __name__ == '__main__':
    c = len(sys.argv)
    if c <= 1:
        print "found zero command variable"
        exit(0)

exec(sys.argv[1])

    if fruit == 'apple':
        print 'this is apple'
    elif fruit == 'oracle':
        print 'this is orange'
    elif fruit == 'banana':
        print 'this is banana'
    else:
        print 'other fruit'

$> foo.py fruit=apple

Traceback (most recent call last):
File "./foo.py", line 18, in
exec(sys.argv[1])
File "", line 1, in
NameError: name 'apple' is not defined

上面的例子执行后，提示'apple'没有定义。执行foo.py fruit="apple"得到的也是同样的错误。从内部输出来看，无论是fruit=apple还是fruit="apple"，exec的参数始终都是fruit=apple，导致exec抱怨apple这个符号没有定义。

我们打开一个Python命令行交互窗口，做如下测试：

$> python
Python 2.7.3 (default, Aug 1 2012, 05:14:39)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exec("fruit=apple")
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in
NameError: name 'apple' is not defined
>>> exec("fruit='apple'")
>>> fruit
'apple'
>>> exec("num=1")
>>> num
1

通过这个小实验可以看出，我们不能将命令行参数直接原封不动的传给exec，我们要对其进行一下加工，加工的效果如下：

fruit=apple => fruit='apple'
num=1 => num=1

【2】

import sys

def __convert(source):
    (var, sep, val) = source.partition("=")
    if val.isdigit():
        return source
    return var + "=" + "\'" + val + "\'"

if __name__ == '__main__':
    c = len(sys.argv)
    if c <= 1:
        print "found zero command variable"
        exit(0)

exec( __convert(sys.argv[1]))

    if fruit == 'apple':
        print 'this is apple'
    elif fruit == 'orange':
        print 'this is orange'
    elif fruit == 'banana':
        print 'this is banana'
    else:
        print 'other fruit'

__convert函数对命令行的参数做了转换，对于数值类的var直接原封不动的返回，否则对于值为字符串的var，将其val用''包裹起来后返回。我们来测试一下新程序：

$> foo.py fruit=apple
this is apple
$> foo.py fruit=orange
this is orange
$> foo.py fruit=watermelon
other fruit

从输出结果来看，我们的预期是达到了^_^。上面的程序只是示例性质的，Python的exec具有运行时执行动态代码的能力，我们在获得这种强大能力的同时，也面临着巨大的风险。一旦恶意代码从外部传入被exec执行，将带来严重的后果。因此对于exec要执行的代码务必要预先进行必要的形式校验。

代码评审，由人治过渡到“法治”

bigwhite — Mon, 08 Jul 2013 08:23:27 +0000

事实证明：有效的代码评审(Code Review，也有叫代码审查的），对保证代码质量具有十分重要的作用。因此这两年来我一直尝试着在这块不断改进和完善，以期望能形成一套合理、规范、有效且高效的代码评审流程，这包括引入在线代码评审系统、走查和在线评审结合、规范评审Request的规模与有效性、设立评审专员等，用心不可谓不良苦 ^_^。大家也的确形成了及时提交Code Review Request或组织进行代码走查的良好习惯。不过我还是发现了一些问题。

* 有些组（我对其影响力不足的^_^）依旧没有严格执行代码评审环节，代码屡屡出现低级错误；
* 走查形式的会议评审缺乏全面性，效果好坏与参与者的“状态”直接相关；
* 在线评审环节缺乏“责任制”，常出现的一种情况是：请求大家评审，结果可能却是大家都没有评审。出现"Request Review Miss"的现象。

这让我陷入思考：长期以来我们在代码评审这块过于依赖人的自觉性，理想地认为每个人都能认识到代码评审的重要性，并认真地执行代码评审的流程或充满激情地参与到其他人发起的代码评审过程中去，但结果事与愿违。这就像党员如何保持纯洁性一样，如果仅仅依靠个人道德/职业水平约束，这事往往是不成的。事实证明人治在中国社会是会造成各种社会问题的。我们的代码评审环节也是一样，我们不能再期望所有人都能和我站在一条认知和激情水平线上，于是我打算尝试向“法治”过渡。

"法"，规则制度也，是团队一致认同的可以提升产品质量的规则制度。以此为前提，我要做的就是设立“检查和预防”机构，即以很低的Cost，检查大家是否按“法”完成了代码评审环节，提醒大家要按“法”进行。我采取了几个措施：

【规范Commit Log 】

这是一个前提工作。实现规范的Commit Log便于后续的检查和监督，同时细化规范的Commit Log信息对代码维护是大有裨益的。在Commit Log中还增加了一些关联信息，方便维护者了解该Commit的背景。初期的模板是这么来确定的：

模板结构：

TITLE
BODY
RELATIONSHIPS

展开后如下：

[Category] Title content

Body content

[BUGID] QC#733 | JIRA#766
[REVIEWID] RB#767
[REVIEWED BY] xx, yy, zz
[SIGNOFF BY] xx

TITLE Category：
   – BUGFIX 代码修复
   – FEATURE 新功能特性添加
   – TASK 诸如代码美化、调整版本号等
   – URGENT 紧急提交，对此类commit，可不做review和拦截

BODY Content：
有关此次修改的详细信息说明

RELATIONSHIPS：
   – [BUGID] 一般用Bug跟踪系统的ID号
   – [REVIEWID] reviewboard上的ID号
   – [REVIEWED BY] xx, yy, zz
   – [SIGNOFF BY] xx

【"全覆盖"原则】

所有变更代码都要发起在线“Code Review Request”，即便是会议走查的代码，会后也要补提“Review Request”。

【“低保”原则】

每个Review Request至少选择两名评审负责人，填到"Request"中，这两个人必须对此Request给出评审意见，这是一个评审的最低保障了，这总比没有人评审要好。当然了其他人也都可以参与评审。只有这两名评审负责人明确提交"ship it" Comment后，该代码才算是通过评审。

【关键路径拦截】

"对不起，若不符合规定，你的工作将无法进行下去"。有了统一的Commit Log模板，我们就可以对大家的代码Commit环节做检查和拦截了。如果代码没有进行评审，无法填写模板中的字段内容，那代码将无法提交到代码库中。如果虚构Commit log内容，这将是极大的错误，在抽查中一旦发现，后果将是很严重的^_^。

当然这一过程中还有很多细节需要考虑，比如Reviewer的选择不能集中在一个人身上，否则会造成热点；再比如紧急提交代码应该如何处理等等。“法治” 是与一定的“国情”相匹配的，并不是所有的组织都需要进行这么严格且略有死板“法治”手段，依团队内组员的专业能力和认知水平而定。

有些公司开发了自己的统一开发平台，将一系列流程都在一套系统中规范了起来，这当然是更好的“法治”了。但在没有这样的平台的前提下，初步使用上述的几个手段，还是会收获一些改进的。

跨过BUG查找的”最后一公里”

bigwhite — Tue, 18 Jun 2013 10:43:34 +0000

如果你看到一个C程序员在通宵熬夜神情紧张地对着电脑敲代码或阅读代码，多数只有两种可能：一是为了赶进度；二就是查找内存Bug。
— 个人感悟

昨晚搞到凌晨一点多，终于算是把一个棘手的Bug的来龙去脉搞清楚了。截至到今天，这个Bug已经困扰了项目组两个核心开发同事达三周之久了。

这个Bug的确很难查找：

   – 首先模拟环境下无法复现该Bug；
   – 生产环境下该Bug是随机出现的，发生频率十分低；
   – Bug出现时并未有dump core等明显异常现象出现，系统依旧运行良好。

得到Bug报告后，我的两位同事就开始对bug引发的问题现象进行了分析，得出了内存被污染的初步结论。之后又在生产环境做了GDB attach到进程的调试，甚至替换了生产环境的版本，利用传统的print语句在关键路径上输出提示信息，试图找到引发Bug的真正原因。但做过这些后，所能得到的结论依旧停留在内存被污染，至于怎么被污染的、在哪个业务流程上被污染的却无从得知。无奈之下，两位同事开始根据 subversion的commit history进行代码比对和分析，试图查找到哪些新增或修改的代码引发了Bug。代码修改量小还好，如果修改数量巨大，这种代码比对就好比大海捞针，我们无法保证注意力自始自终是集中的，结果两位同事也的确没有从代码变更中发现什么蛛丝马迹。这类Bug会让你有一种有力无处施展的感觉，面对这样的Bug，我的两位开发人员似乎也失去了信心和思路。

下面简要描述一下这个Bug：

有这样一个字段数目众多的结构体foo_t，这里仅列出bug相关的几个字段e、c、flag、pdata：

struct foo_t {
    … …
    char e[XX_SIZE];
    char c[XX_SIZE];
    char flag;
    data_t *pdata;
    … …
}；

业务逻辑是：

if (flag) {
处理e、c两个字段；
}

bug现象：值本是1的flag字段被污染，值变成了0，导致e、c两个字段没有被做处理，从而引发业务异常，导致客户投诉。我的同事曾经做过如下尝试，以确定内存污染的行为特点，她在flag之前又加了一个字段flag1：

struct foo_t {
    … …
    char e[XX_SIZE];
    char c[XX_SIZE];
    unsigned int flag1;
    char flag;
    data_t *pdata;
    … …
}；

在生产环境下运行得到的结果是flag1和flag值正常，但字段c的尾部字节遭到了污染。现象已经十分明确，离真相就差那最后一公里了。

对于上面的内存污染问题，我首先会怀疑在处理flag或c之前的字段时出现了缓冲区溢出，导致后面字段的内容被整体或局部覆盖。不过从bug现象来看，这个思路也有说不通的地方，那就是为何是c的尾部字段被污染，而不是从头部开始呢？不过我们依旧沿着这个思路追查了e以及e的诸多前驱字段，细致的分析了代码，但没有发现溢出点。

c或flag的后继字段比如pdata要想污染c或flag则必须具备更多条件，至少要有操作&pdata的代码，之前基本认为这不太可能。但现在仅有这一条路可以继续走下去了，也只能沿着这条路走下去。事实证明我们走的没错。在后续的处理流程中有这样的一个函数：

int func(void *p, int size)

这个函数本来是用于处理data_t*变量的，但由于编码者的疏忽，将&pdata传给了p，另外size这个参数也传了一个错误的值，估计是滥用了copy&paste。而func函数体中对p指向的内存地址做了修改，这个修改直接污染了 ((char*)&pdata + size)起始的那片内存块儿，这就是问题的真正原因所在。这样看来pdata并未污染其所在的foo_t实例中的flag或c字段，而是污染了其他foo_t实例中的flag或c字段，因为这些实例都放在一个mem block pool中的，所以这还是一个随机的远距离内存污染^_^。

我走完了BUG查找的最后那一公里，到达了终点。这个BUG的查找确实不易，但并非遥不可及，为何我的两位同事就停在离真相只有一公里的地方而踌躇不前了呢？对此我也做了一些考量，希望能在日后的BUG查找方面给予帮助。

要跨过BUG查找的那最后一公里，可从如下几个方面着手努力：

* 收罗证据，不放过一处可疑之处

这是准备工作，就好比警察查看罪案现场，哪怕是一根毛发，一处异物也不能放过。一般来说我们至少要收集到Bug发生时的各方面信息，包括：

- 系统日志
这个时间点上各个模块的日志都要搜罗到；

- core文件
如果bug引发core dump，那core文件是bug查找的最佳入口；

- 通信数据包内容
对于很多后端服务程序而言，不合法的通信数据包常常会引发Bug，我经手的类似Bug就不止一起了。必要时通过抓包工具将通信包抓到文件中以备后用。

- CPU/内存/磁盘实时状况
千万不要小视这些信息。如果发现CPU过高，则很可能代码存在死循环的可能（后pstack进程号，则可直接找到问题所在）；如果磁盘满，则可以很好解释数据不完整的异常；如果mem占用过高，则可以解释分配内存异常或性能下降等问题。

- 系统操作日志
如果有管理员的操作行为的话，我们也不要放过，将操作日志（一般系统都有保存，并需要对这些日志进行定期审核）截取并保留，以备后用。

- 操作系统/硬件相关异常信息等。
如果是因为OS或硬件异常导致的Bug，那搜集到这些信息就太重要了，否则你将付出惨重的Bug查找代价。

Bug查多了你就会有这种感悟：证据用时方恨少啊！

* 沉下心，保持清晰思路

BUG有难有易，简单的Bug大家都能应付，而困难的Bug，就要比拼能力和经验了。要想解决掉Bug，务必要沉下心，不急不躁，这是保持大脑始终有清晰思路的前提。

能用工具（比如GDB）调试出来的Bug，都不是最难的问题，因为现场就摆在你的面前，你可以看到一切蛛丝马迹。最难的问题最终都是要通过脑力分析出来的。

解决问题前，要根据之前搜罗的证据，形成自己的查找思路。没有思路是可怕的。没有思路的时候，也不要急于开始查，那样只会乱套。应根据已有的蛛丝马迹，行成一些思路，哪怕这个思路你自己都不是很肯定，先按这个思路做做看，也许走出一步后，你又能收获新的信息，形成新的思路。就这样敏捷地向前进，边向前探索边定期回顾。

* 知晓原理，缩小查找范围，形成正确思路

要保持清晰正确的思路，开发人员对系统的运行原理要做到十分清楚，这样可以缩小查找范围，重点突破。就好比上面的那个bug例子，我们要知道 c/flag被污染有几种潜在的可能，并形成多种思路，然后沿着这几种可能的思路继续走下去。在这次查找过程中，想必两位同事恰恰是在原理这方面没有理解透彻吧。

* 质疑，从自己的代码开始

查Bug就要抛弃“不可能”，拥抱“质疑一切”。而质疑要从自己的代码开始。程序员或多或少都有一种“自负”的心态，骨子里会认为自己的代码肯定是正确的。如果出现问题，一定是其他人代码的问题，哪怕是OS这样总体来说十分稳定的平台也会成为被首先质疑的对象。不过事实证明，错误多出在我们自己的代码中，毫无理由的去怀疑操作系统、怀疑你使用的第三方库，多半会南辕北辙，浪费你宝贵的查找时间。

* 拥抱调试技巧和工具

必要的调试技巧是Bug查找的基本功底，这些技巧在涉及内存问题查找过程中相当有用。

— print语句
不用多说，print语句是最简单、最常用的调试手段，在代码任意位置，根据你的需要，输出信息，帮助你分析bug原因。其唯一的缺点就是可能需要你重新 build代码和部署你的应用。

— gdb切入进程地址空间查看堆栈
利用gdb一类的专用调试工具可在代码运行时切入进程地址空间，实时查看数据变化。你也可以在gdb下执行应用，获得同样的效果（适合单进程应用）。

— 调试版中采用magic number + assert
C程序的bug多为内存问题。常见的内存越界访问或污染的调试手段是在代码中为内存块添加magic number，并在特定环节用assert保证该magic number的值是没有被修改的。一旦值改变了，则说明问题发生在执行流的两次assert之间的某个地方，后续可进一步缩小assert间隙，直到定位到问题。

— 让bug尽可能的容易复现
一个可以在模拟环境下复现的Bug总是比较好查的。出于这个考虑，我们可通过放大问题区域来尽可能更容易的复现bug，比如将一个字节的字段改为4个字节，这样可能占据更多被污染的区域，比较利于Bug的复现（但这不总是ok的）。

* 把握节奏，避免陷入惯性思维

一些比较难fix的Bug，其查找过程可能会十分漫长，就像这次我们遇到的这个问题。这就需要我们的开发人员把握好Bug查找的节奏，因为长时间调试和查问题容易让人陷入惯性思维，反倒不利于Bug的查找。一旦意识到自己进入惯性思维后，可考虑换种活动做做，比如出去散散步、洗个热水澡等。或者给其他人员讲解你的查找思路，这个过程中自己可能会发现思路上的缺陷，或者由他人指出你思路方面的问题。

感觉Bug查找是一门手艺活，要学会慢工出细活，这总比不出活儿的要好，尤其是在面对那些十分诡异的内存Bug时。

《Understanding and Using C Pointers》要点先睹为快

bigwhite — Mon, 27 May 2013 19:00:05 +0000

如果你问十个C程序员：你觉得C语言的核心是什么？这十个程序员都会回答：指针。

指针具备成为C语言核心的两个关键要素：强大与争议。

* 指针的强大源自于其天生与机器内存模型的适配。使用指针让代码紧凑，并可获得仅次于汇编代码的执行效率；使用指针可以让C程序员毫不费力地尽情操纵着内存中的每个byte甚至是bit；使用指针可以为C程序员提供无与伦比的操作灵活性。总之，在C语言中指针几乎是无所不能的代名词。得指针者得天下，没有指针，C语言将变得平庸。

* 成也指针，败也指针。指针的争议之处就在于其在赋予C程序员无比强大的Power的同时，也常常带来无穷的烦恼甚至灾祸，比如内存问题、调试困难或因指针导致的程序崩溃等。就好比人类社会，做核心人物有争议是难免的，比如足球界有马拉多纳，跳水界有菲尔普斯，斯诺克界有奥沙利文^_^。

好了，言归正传，我们回到C语言图书上来。目前市面上的C语言书籍，无论国内国外，无论经典还是山寨，基本都是百科大全型，将C语言讲的面面俱到。比如最近的一本大而全的经典应当属《C Programming , A Modern Approach》，中文版书名为《C语言程序设计：现代方法》第2版。以至于发展到今天，C语言似乎也没啥可讲的了，新出的C语言书大多是与前辈们雷同的作品。近两年来也有O'reilly出版的C语言书籍，比如：

*《Head First C》
*《21st Century C – C Tips from the New School》

前者是典型的Head First风格的C教程，后者则是另辟蹊径，结合C语言外延（构建、调试、打包、版本控制、面向对象与C、知名C语言开源库等)进行讲解。这两本书虽形式有变化，但终究脱离不开百科大全型，针对C的核心-指针并未有较多的深入探讨。而市场上专门写指针的书也稀少的很（似乎鬼子国那边有一本，叫什么《征服C指针》），唯一的一本书名与指针扯上关系的书《Pointers on C》（中文名“C和指针”）其实依旧是一本C语言大全。于是乎国外著名出版社O'Reilly今年5月出品了一本专门讲解C语言核心 – 指针的书《Understanding and Using C Pointers》，以满足C程序员深入理解C语言核心并实现进阶的诉求。O'Reilly就是O'Reilly，总是能抓住C语言书籍方面的深度阅读需求^_^。

《Understanding and Using C Pointers》是个小册子，拢共才200多页，但内容却全部是围绕C语言指针展开的，从最基本的指针声明与操作、C内存模型、动态内存分配，讲到指针与数组、结构体、字符串的关系，再到最后指针的高级特性：强制转换、Strict Aliasing、线程共享、多态支持等，由浅入深的进行细致的剖析。其作者认为作为C语言核心的指针值得花200页篇幅去讲解，而且期望所有读者在读完此书后能对C指针有个扎实的理解。总之，这本书对系统C程序员理解C语言的核心-指针是大有裨益的。在其中文版（已经由图灵出版社引进版权了）尚未出版之前，这里带你先了解以下本书的要点：

第一章简介

1、指针与内存

【指针声明语法】
int *pi;

【理解复杂指针声明】
方法：从后向前读，例子：

const int *pci;

   pci is a variable                                   pci
   pci is a pointer variable                           *pci
   pci is a pointer variable to an integer             int *pci
   pci is a pointer variable to a constant integer     const int *pci

【地址操作符】
pi = #

    【输出指针值】
    通过%x、%o、%p输出(printf)指针的值，一般使用%p（%p输出结果不一定等同于%x，是与实现有关的）。例子如下：
   int num = 0;
     int *pi = #
   printf("Address of num: %d Value: %d\n",&num, num);
     printf("Address of pi: %d Value: %d\n",&pi, pi);

Address of num: 4520836 Value: 0
Address of pi: 4520824 Value: 4520836

    【通过间接访问操作符解引用指针】
      间接访问操作符*，使用例子如下：
   int num = 5;
     int *pi = #
     printf("%d\n",*pi); // Displays 5
     *pi = 200;
     printf("%d\n",num); // Displays 200

【指向函数的指针】
void (*foo)(); // 这个变量声明中的foo就是一个指向函数的指针

【Null概念】

null concept
赋值为NULL的指针变量表示该指针不指向任何内存地址。

null pointer constant
null concept的具体支撑实现，其常量值可能是常量值0，也可能不是。依具体实现而定。

NULL macro
在许多标准库实现中，NULL定义如下：#define NULL ((void *)0)，这也是我们对NULL的通常理解。当然这是依Compiler的具体实现而定的。如果编译器使用非全0位模式实现了NULL，那该编译器就要保证在指针上下文中使用的NULL或0是null pointer。

ASCII NUL
一个全0的字节。

null string
一个不包含任何字符的空字符串。C字符串在最后都放置一个结尾0值。

null statement
只包含一个分号的空语句。

         指向void的指针
             指向void的指针被成为通用指针，可以用于引用任意类型的数据。它有两个属性：
                    – 指向void的指针与指向char类型的指针具有相同的内存表示与内存对齐约束。
                    – void指针永远不等于其他类型指针，两个赋值为NULL的void pointer是相等的。

             任何指针都可以被赋给一个void pointer，并且之后还可以被转换回其原来的类型。
             int num;
             int *pi = #
             void* pv = pi;
             pi = (int*) pv;

   void pointer用于数据指针，而不是函数指针。
             全局void pointer或static void pointer在程序启动时被初始化为NULL。

2、指针大小与类型
        在多数现代平台上，指针的大小都是相同的，与其类型无关。指向char的指针与指向结构体的指针大小相同。
        指向函数的指针可能与指向数据类型的指针大小有差异，这要依具体实现而定。

     【内存模型】
             在不同机器和编译器下，C语言原生类型的大小是不同的。
             描述不同数据模型的一般记法：I In L Ln LL LLn P Pn，例如LP64、ILP64、LP32等。

     【预定义的指针相关类型】
            size_t 用于表示对象的大小的一个安全类型。
            ptrdiff_t 用于处理指针运算
            intptr_t和uintptr_t 用于存储指针地址

int num;
intptr_t *pi = #

3、指针操作符

     【指针运算】
       pointer + integer
           指针实际移动的字节数 = integer + sizeof(integer_type)
           void* pointer的指针运算操作行为是未定义的，依赖Compiler的具体实现。

pointer – integer
指针实际移动的字节树 = integer – sizeof(integer_type)。

pointer1 – pointer2
两个指针所指地址间的差值，常用于判断数组中元素的先后次序。

比较pointers

【指针比较】
指针可以使用标准的比较操作符（> and <）进行比较，可用来判断数组中元素的先后次序。

4、指针的通常用法

     【多级间接寻址】
      双指针(double pointer) – 指向指针的指针。

            char *titles[] = {"A Tale of Two Cities",
                        "Wuthering Heights","Don Quixote",
                        "Odyssey","Moby-Dick","Hamlet",
                        "Gulliver's Travels"};
      char **bestBooks[3];
      bestBooks[0] = &titles[0];
      bestBooks[1] = &titles[3];
      bestBooks[2] = &titles[5];

            间接寻址的级数并没有限制，但过多的级数会让人难以理解。

【常量和指针】

            指向常量的指针
         const int limit = 500;
         const int *pci = &limit;
                  *pci = 600；/* Error，我们不能解引用一个常量指针并修改其所指的内存值 */

                 const int *pci <=> int const *pci;

            指向非常量的常量指针
         int num;
         int *const cpi = #
                  *cpi = 25; /* 可以解引用常量指针并修改其所指的内存的值 */
         int limit;
         cpi = &limit; /* Error，我们不能为常量指针重新赋新值 */

         const int limit1 = 300;
         int *const cpi1 = &limit1; /* Warning: 指向非常量的常量指针被用常量的地址初始化了 */

指向常量的常量指针
         const int limit = 300;
   const int *const cpci = &limit; /* 声明后，我们不能通过cpci修改limit，也不能为cpci重新赋值 */

            指向“指向常量的常量指针”的指针
         const int limit = 300;
         const int *const cpci = &limit;
         const int *const *pcpci = &cpci;

第二章 C语言动态内存管理

在运行时通过函数手工从heap分配和释放内存的过程称为动态内存管理。

1、动态内存分配
    【使用malloc函数】
    int *pi = (int*) malloc(sizeof(int));
      *pi = 5;
      free(pi);

    【内存泄漏】
            – 丢失了内存地址
            – 没有调用free函数释放内存

2、动态分配内存函数
      malloc、realloc、calloc、free
      是否对malloc出的内存起始地址进行强制转型
             int *p = (int*)malloc(4);
             void *pointer可以转换为任意类型指针，没有强制转型也可以。
             但显式的强制转型可以通过代码看出意图，并且与C++编译器(包括早期C编译器)兼容

      你不能用内存分配函数分配的内存去初始化全局或Static变量。
      alloca函数用于在栈上动态分配内存，函数结束时，这块内存自动释放；但alloca不是标准C库函数，移植性差。
      C99支持可变长度数组(VLA)，数组声明时的元素个数可以是运行时才能确定值的变量，但数组size一旦在运行时被确定，数组大小就无法再做改变：
   void compute(int size) {
           char* buffer[size];
           …
   }

3、悬挂指针
     被free后依然引用原先内存地址的指针，称为dangling pointer。
     悬挂指针可能导致如下问题：
            – 如果访问其引用的内存，将导致不可预期的结果
            – 如果内存不可访问了，将导致段错误
            – 存在潜在的安全风险。

     悬挂指针引起的问题调试起来十分困难，以下几种方法用于避免发生悬挂指针问题或快速查找悬挂指针问题：
            – free后，设置指针为NULL；
            – 编写一个替代free的函数；
            – 用特定值填充free的内存块，便于快速定位dangling pointer问题
            – 使用第三方工具检查dangling pointer问题

第三章指针与函数

当与函数一起使用时，指针有两个方面发挥重要作用：
– 当指针以参数形式传递给函数时，允许函数修改指针所指内存区域的值，并且这种传递方式更加高效；
– 声明函数指针时，函数的名字被求值为函数的地址。

1、程序栈和堆

    【程序栈】
      栈和堆共享一块内存区域。栈在这块区域的低地址部分，堆在高地址部分。
      程序栈用于存放栈帧(stack frame)，栈帧中存放的是函数的参数与local变量。
      栈增长方向：向上；堆的增长方向：向下。

    【栈帧的组成】
     一个栈帧包含如下几个元素：
           – 返回地址
           – 本地变量
           – 函数参数
           – 栈指针(Stack pointer)和栈帧指针(base pointer or frame pointer)

Stack pointer和frame pointer用于运行时系统对栈的管理。前者总是指向栈的顶端；后者指向栈帧内的某个地址，比如函数的返回地址；frame pointer辅助程序访问栈帧内的元素。

     栈帧的创建，见下面例子：
        float average(int *arr, int size) {
            int sum;
            printf("arr: %p\n",&arr);
            printf("size: %p\n",&size);
            printf("sum: %p\n",&sum);

            for(int i=0; i                 sum += arr[i];
            }
            return (sum * 1.0f) / size;
    }

      average的栈帧中沿着栈“向上”的方向，依次推入的是：
            – 参数 size、arr （与声明的顺序恰好相反）
            – 函数average调用的返回地址
            – 本地变量sum（如果有多个本地变量，推入栈的顺序也与变量声明顺序相反）

每个线程通常都在自己的栈中创建栈帧。

2、指针作为参数和返回值

      C语言的参数是“按值传递”的，包括指针本身，函数内使用的是参数的copy。
      在处理大数据结构时，将指针作为参数传递给函数或作为返回值会使得程序执行起来更加高效（只是copy一个指针大小的数据，而不是指针所指向的数据对象大小）。
      另外一个以指针作为函数参数的目的是希望在函数内部对数据进行修改。
      当传递一个指向常量的指针给函数时，其意图为不希望函数内部对指针所指的数据进行修改。例如void passingAddressOfConstants(const int* num1, int* num2)，不希望num1所指数据被修改。
      将指针作为返回值返回时，应避免以下几个常见问题：
            – 返回未初始化的指针
            – 返回指向非法地址的指针
            – 返回指向函数本地变量的指针
            – 返回指针后，没有释放其所指的内存块

      如果函数要修改的不是参数中指针所指的数据，而是指针本身所指的内存地址，那么应以double pointer形式作为函数参数：

        void allocateArray(int **arr, int size, int value) {
            *arr = (int*)malloc(size * sizeof(int));
            if(*arr != NULL) {
                for(int i=0; i                     *(*arr+i) = value;
                }
            }
        }

int *vector = NULL;
allocateArray(&vector,5,45);

3、函数指针
函数指针就是存放函数地址的指针。
使用函数指针可能导致程序运行变慢（可能感知不到），因为函数指针的使用可能导致CPU无法正确的运用分支预测，导致CPU流水线中断。

【声明函数指针】

      函数指针的声明看起来像函数原型，比如：void (*foo)(int i);
程序员应该确保通过函数指针调用函数的正确使用，因为C编译器不会检查是否正确的为函数指针传入正确的参数（类型、顺序以及个数）。
      通常我们用typedef声明一个函数指针类型，比如：
          typedef void (*funcptr)(int i)；
          funcptr fp = foo;

    【函数指针强制转型】

      一个类型的函数指针可以被强制转为另外一种类型函数指针。
      转型后的指针 == 转型前的指针

        typedef int (*fptrToSingleInt)(int);
        typedef int (*fptrToTwoInts)(int,int);
        int add(int, int);
        fptrToTwoInts fptrFirst = add;
        fptrToSingleInt fptrSecond = (fptrToSingleInt)fptrFirst;
        fptrFirst = (fptrToTwoInts)fptrSecond;
        printf("%d\n",fptrFirst(5,6));

在函数指针间转换，很可能导致函数调用失败。

第四章指针与数组

1、数组概述

数组与指针记法关系紧密，在特定上下文中可以相互替换。
数组内部表示中并没有数组长度信息。

【一维数组】
int vector[5];

一维数组是一个线性结构。数组下标起始于0，终止于(元素个数-1)。

【二维数组】
int matrix[2][3] = {{1,2,3},{4,5,6}};

二维数组使用行和列标识数组元素。这类数组需要被映射到一个一维地址空间中。
在C中，二维数组的第一行放在内存的最开始处，接下来是第二行，…，直到最后一行，这就是所谓的“行主序”。

【多维数组】
    int arr3d[3][2][4] = {
        {{1, 2, 3, 4}, {5, 6, 7, 8}},
        {{9, 10, 11, 12}, {13, 14, 15, 16}},
        {{17, 18, 19, 20}, {21, 22, 23, 24}}
};

二维以上的维数的数组称为多维数组，其元素内存分配依旧遵守二维数组那种映射方式。

2、指针记法(notation)与数组

指针记法与数组记法在一定场合可以互换，但两者并不完全相同。
数组名单独使用时，我们得到的是数组的地址；该地址等同于数组内第一个元素的地址。

int vector[5] = {1, 2, 3, 4, 5};
int *pv = vector;
int (*pv)[5] = &vector;

vector与&vector不同，前者返回指向一个整型变量的指针（int *），后者返回一个指向整个数组的指针(int[5] *)。
pv[i] <=> *(pv + i)
*(pv + i) <=> *(vector + i)

【指针与数组间的不同】

int vector[5] = {1, 2, 3, 4, 5};
int *pv = vector;

sizeof(vector) = 20 != sizeof(pv)

pv是lvalue，可以被修改而指向不同的地址；比如pv = pv + 1
而vector不能被修改。vector = vector + 1这个表达式是错误的，不过pv = vector + 1是ok的。

【使用malloc创建一维数组】
    int *pv = (int*) malloc(5 * sizeof(int));
    pv[3] = 10;
     可使用realloc改变malloc创建的数组的大小。

3、传递一维数组
    两种记法：数组记法和指针记法，分别如下：
    void displayArray(int arr[], int size);
    void displayArray(int* arr, int size);

无论哪种，displayArray函数体内int arr[]或int *arr都将以int *arr方式使用，即数组名退化为指针，sizeof(arr) = 指针长度，而不是数组总长度。

   【一维指针数组】

    int* arr[5];
    for(int i=0; i<5; i++) {
        arr[i] = (int*)malloc(sizeof(int));
        *arr[i] = i;
    }

   【指针与多维数组】
         多维数组可以看成是由子数组组成的，就好比二维数组的每行都可以看成是一个一维数组。
         int matrix[2][5] = {{1,2,3,4,5},{6,7,8,9,10}};
         int (*pmatrix)[5] = matrix;

4、传递多维数组

   void display2DArray(int arr[][5], int rows)；<=>
   void display2DArray(int (*arr)[5], int rows)；
      上面两个版本是等价的。两个版本都指定了列的值，因为编译器需要知道每行的元素个数。

注意第二个版本不等价于void display2DArray(int *arr[5], int rows)；

在void display2DArrayUnknownSize(int *arr, int rows, int cols)的函数体实现中，你不能使用arr[i][j]，因为arr并未被声明为二维数组。

5、动态分配二维数组

【采用不连续的内存分配方式】

    int rows = 2;
    int columns = 5;
    int **matrix = (int **) malloc(rows * sizeof(int *));
    for (int i = 0; i < rows; i++) {
        matrix[i] = (int *) malloc(columns * sizeof(int));
    }

【采用连续内存分配的方式】

    int rows = 2;
    int columns = 5;
    int **matrix = (int **) malloc(rows * sizeof(int *));
    matrix[0] = (int *) malloc(rows * columns * sizeof(int));
    for (int i = 1; i < rows; i++)
        matrix[i] = matrix[0] + i * columns;

int *matrix = (int *)malloc(rows * columns * sizeof(int));

第五章指针与字符串

1、字符串基础

     字符串：以ASCII结尾'\0'字符结尾的字符序列。
     分类：字节字符串(byte string) – char类型字符序列
               宽字符串（wide string) – wchar_t 类型字符序列（每个字符16bit or 32bit，依编译器实现而定）
     字符串声明：char header[32] or char *header；

【字符串字面量池(String literal pool)】
字符串字面量定义后将被放在字面量池中。这块内存区域存放的是组成字符串的字符序列。当一个字面量多次使用时，通常在字面量池中只存储一份该字符串。这将降低程序的内存使用量。并且通常情况下，字面量池中的字符串是immutable的。

大多数编译器都提供了编译开关，用于指示是否关闭字符串字面量池，比如Gcc的-fwritable-strings。

【字符串初始化】、
char *header = "Media Player";

or
char header[] = "Media Player";

      or
      char header[13];
      strcpy(header,"Media Player");

      or
      char *header = (char*) malloc(strlen("Media Player")+1);
      strcpy(header,"Media Player");

2、标准字符串操作

      比较字符串：strcmp
      拷贝字符串：strcpy
      连接字符串：strcat

3、传递字符串

      传递简单字符串：
    size_t stringLength(char* string) ;
      size_t stringLength(char string[]);

传递字符串常量：
size_t stringLength(const char* string);

4、返回字符串

         返回一个字面量：return "Boston Processing Center"；
         动态分配的内存：
         char* spaces = (char*) malloc(number + 1);
         … …
         return spaces;
         返回local字符串的地址是危险的。

5、函数指针与字符串

第六章指针与结构体

1、简介

【如何为结构体分配内存】
结构体的大小往往大于该结构体所有字段大小之和，因为有数据对齐的需求，导致编译器在进行结构体内存分配时进行了padding操作。特定数据类型具有一定的对齐要求，比如short类型的字段要求其地址能被2整除，而integer类型的字段要求其起始地址能被4整除。

      考虑到这些多余分配的内存，你应该谨慎对待如下操作：
      – 小心使用指针运算
      – 结构体数组的元素间有多余内存空间

【结构体内存释放】
为结构体分配内存时，运行时不会自动为结构体内的指针字段分配内存；同理，释放结构体内存时，运行时也不会自动释放结构体内指针字段所指向的内存。

【避免malloc和free的额外开销】
malloc和free多次重复调用时，会给程序带来额外的开销。一个解决方法就是自己维护一份已分配的结构。需要时，从这个池里取出一份，释放时，直接返回给池中。如果没有可用的结构时，才考虑新创建一个。

2、使用指针支持数据结构

无论是简单还是复杂的数据结构，指针都提供了更加灵活的支持，包括链表、队列、栈以及树等。

第七章安全问题以及不当使用指针

深入理解指针以及其正确的使用方法有利于开发出安全可信赖的应用。

OS引入了一些提升安全的技术，比如 Address Space Layout Randomization和Data Execution Prevention。

【Address Space Layout Randomization (ASLR) ，地址空间布局随机化】
ASLR技术使得程序的数据区域随机布局，数据区域包括：代码、栈、堆。随机的放置这些区域让代码攻击行为很难精确预测特定代码的内存地址并使用它们。

【Data Execution Prevention(DEP)，数据执行保护】
DEP技术会阻止执行非执行数据区域中的代码。在一些攻击中，一些非执行数据区域中的数据被恶意覆写为代码，执行权也被转移到那里。但有了DEP后，这些恶意代码将无法执行。

1、指针声明与初始化

   【不正确的指针声明】
     int* ptr1, ptr2;
      ptr1是指针，但ptr2只是一个整型变量。

正确声明方法：int *ptr1, *ptr2; /* 更好的做法是每行仅声明一个变量 */

      下面做法存在同样的问题：
   #define PINT int*
   PINT ptr1, ptr2;

      用typedef就没有问题了：
   typedef int* PINT;
   PINT ptr1, ptr2;

【使用指针前未初始化】
使用前未做初始化的指针，常称作野指针（wild pointer)：

   int *pi;
    …
   printf(“%d\n”,*pi);

    【处理未初始化的指针】
      指针脸上没有写自己是否做过初始化^_^。通常有三种方法用于对付未初始化的指针：
        – 总是将指针初始化为NULL；
        – 使用assert函数
        – 使用第三方工具

2、指针使用问题

      缓冲区溢出(Buffer overflow)可能由以下原因导致：
      – 访问数组元素的时候没有检查下标值
      – 做数组指针相关运算时不够谨慎
      – 用gets之类的函数从标准输入读取字符串
      – 使用strcpy和strcat不当

【测试NULL】
调用malloc后，总是检查返回值是否为NULL。

     【误用解引用操作符】
       int num;
       int *pi;
       *pi = &num

【悬挂指针】

【访问数组越界】

       char firstName[8] = "1234567";
       char middleName[8] = "1234567";
       char lastName[8] = "1234567";
       middleName[-2] = 'X';
       middleName[0] = 'X';
       middleName[10] = 'X';

【错误计算数组大小】
当将数组作为参数传递给函数时，务必将函数的Size一并传入，这个Size信息将避免数组访问越界。

     【误用sizeof操作符】
        int buffer[20];
        int *pbuffer = buffer;
        for(int i=0; i             *(pbuffer++) = 0;
        }

sizeof(buffer)=>sizeof(buffer)/sizeof(buffer[0]);

      【总是匹配指针类型】
      【有界指针(bounded pointer)】
      【字符串安全问题】
        对strcpy和strcat使用不当，会导致缓冲区溢出。
        在C11标准中加入了strcat_s和strcpy_s函数，如果发生缓冲区溢出，它们会返回错误。

      【函数指针问题】
       不要将函数赋值给签名不同的函数指针，这很可能将导致未定义行为发生。

3、内存释放问题
      【两次free】
      【清除敏感数据】
         一个良好的实践是覆写哪些不再需要的敏感数据。

        char *name = (char*)malloc(…);
        …
        memset(name,0,sizeof(name));
        free(name);

4、使用静态分析工具

比如Gcc -Wall等。

第八章其他零碎的知识点

1、指针转型
      指针转型有几个原因：
      – 访问特定目的的地址
      – 分配一个地址代表一个端口
      – 决定机器的endianess

    【访问特定的地址】
      #define VIDEO_BASE 0xB8000
      int *video = (int *) VIDEO_BASE;
      *video = 'A';

    【访问一个端口】
      #define PORT 0xB0000000
      unsigned int volatile * const port = (unsigned int *) PORT;
      *port = 0x0BF4; // write to the port
      value = *port; // read from the port

    【判断机器的endianess】
      int num = 0×12345678;
      char* pc = (char*) #
      for (int i = 0; i < 4; i++) {
          printf("%p: %02x \n", pc, (unsigned char) *pc++);
      }

2、Aliasing、Strict Aliasing和restrict关键字

两个指针同时指向一块相同的内存地址，这两个指针被称为aliasing。

     int num = 5;
     int* p1 = #
     int* p2 = #

aliasing的使用对编译器生成的代码强加了限制。
如果两个指针引用相同位置，每个指针都可以修改这块地址。当编译器生成读写这块内存的代码时，不总是可以通过将值存储在寄存器中这种办法来优化代码。对每次引用，将强制使用机器级别的低效load和store操作。

Strict Aliasing：另外一种形式的aliasing。strict aliasing不允许不同类型的指针指向同一块内存区域。下面代码：一个指向整型的指针alias了一个指向float类型的指针了，这违反了Strict Aliasing的规则。

    float number = 3.25f;
    unsigned int *ptrValue = (unsigned int *)&number;
    unsigned int result = (*ptrValue & 0×80000000) == 0;

如果仅仅是符号标志和修饰符不同，是不会影响strict aliasing的，下面的语句是符合Strict aliasing规则的：

    int num;
    const int *ptr1 = #
    int *ptr2 = #
    int volatile ptr3 = #

有些场合，相同数据的不同表示是很有用处的，下面一些方法可以避免与Strict aliasing规则冲突：
        – 使用Union: 多个数据类型的联合体可以规避strict aliasing
        – 关闭strict aliasing ：利用编译器提供的开关将strict aliasing关闭（不建议这么做哦），
                     比如Gcc提供的一些开关：
                 -fno-strict-aliasing 关闭strict aliasing
                 -fstrict-aliasing 打开strict aliasing
                 -Wstrict-aliasing 针对strict aliasing相关问题给出警告
        – 使用char pointer：char pointer可以alias任何对象。

       【使用Union实现一个值的多种方式表示】

        typedef union _conversion {
            float fNum;
          unsigned int uiNum;
        } Conversion;
        int isPositive1(float number) {
          Conversion conversion = { .fNum =number};
          return (conversion.uiNum & 0×80000000) == 0;
        }

由于没有指针，所以不存在违反Strict aliasing的问题。

【Strict Aliasing】
编译器假设多个不同类型的指针不会引用到同一个数据对象，这样在strict aliasing的规则下，编译器才能够实施一些优化。如果假设不成立，那很可能发生意料之外的结果。

即使是两个拥有相同字段，但名字不同的结构体，其对应的指针也不能引用同一个对象。但通过typedef结构体类型指针与原类型指针可以引用同一个数据对象。

         typedef struct _person {
            char* firstName;
            char* lastName;
            unsigned int age;
        } Person;
        typedef Person Employee;
        Person* person;
        Employee* employee;

       【使用restrict关键字】
         使用restrict关键字，意即告诉编译器这个指针没有被alias，这样编译器将可以进行优化，生成更为高效的代码。通常的优化方法是缓存这个指针。
         不过即便使用了restrict关键字，对编译器来说也只是一个建议，编译器可自行选择是否进行优化。
         建议新代码中都要使用restrict关键字。

        void add(int size, double * restrict arr1, const double * restrict arr2) {
            for (int i = 0; i < size; i++) {
                arr1[i] += arr2[i];
            }
        }

        double vector1[] = {1.1, 2.2, 3.3, 4.4};
        double vector2[] = {1.1, 2.2, 3.3, 4.4};
        add(4,vector1,vector2);
         以上是add函数的正确用法。

        double vector1[] = {1.1, 2.2, 3.3, 4.4};
        double *vector3 = vector1;
        add(4,vector1,vector3);
        add(4,vector1,vector1);

这个例子中vector3与vector1指向同一份数据，也许add可以正常工作，但这个函数的调用结果并不那么可靠。

标准C库中有多个函数使用了restrict关键字，比如void *memcpy(void * restrict s1, const void * restrict s2, size_t n)等。