powershell 死循环CPU使用量

从下图来看，windows的powershell的死循环程序并没有占用100%的cpu，为什么？

原因： 这里的 12.39*8 ~= 100 ； 因为这个电脑是4核心8线程的，满负荷是800%，将800%折合成100%的话，100%就折合成12.38%左右，所以说，这里的12.38%就是一个核心的意思；

当启动到9个powershell死循环的时候，就不能再保证每个进程占用12%的cpu了：

关于软件开发方法

以前的软件开发非常注重方法，注重质量，软件开发周期长。

现在的软件开发更注重快速迭代。

一个很重要的原因是：

以前的软件多是开发完卖出去的；

现在的软件大多是自己提供线上服务的；

所以：

对于前者，你不可能让客户每天部署一个新版本；

对于后者，发现问题可以及时修正，成本很小。

以前开发软件，更关心能用，可用。至于可维护性并不重要，毕竟复杂的维护还能收更多的维护费用呢。

bash 之 信号处理

缘起：

docker stop 时往往会比较慢，起原因多半是docker 容器的init进程没有正确处理信号所致；docker stop的行为为： 先发送一个SIGTERM(15) 信号给init进程，如果一段时间（默认10s）后，依然没有退出，就直接发送 -9 信号，常常我们会登上10s，最终，进程的退出依然是仓促的；所以，实现一个好的init进程非常重要。

想用bash写一个docker 的init进程，当收到SIGTERM信号时，通知容器中的其他进程退出，其他进程退出后自己再退出，这样的话，其他进程可以有时间优雅退出，而且stop操作还可能很快完成。

版本1：

实际并不凑效； 原因： bash 在执行外部命令的时候，是不处理信号的

 

改进：

不足：当有信号到时，依然要等sleep 睡足才能处理信号，如果每次sleep 时间足够短，则总是启动sleep进程也非常不优雅，本身总是看到一个sleep进程已经够闹心的了

 

改进：

优点：

  1. 看不到sleep函数了
  2. read line 并不消耗多少资源
  3. 虽然 read 函数是阻塞的，但是却不影响bash实时处理信号

缺点：

  1. 创建容器时需要 -it 选项，因为bash标准输入需要是正常的，才能是的read不会失败而正常阻塞，否则，read会一直失败，导致死循环占用100% CPU ; 安全一些的做法是，发现read失败直接退出

 

测试脚本：

执行该脚本，然后发送信号15给bash进程，发现：

  • 当执行到sleep 10 的时候，不能实时处理信号
  • 当阻塞在read时，可以实时处理信号

 

下面这种写法也比较简单，可以实时处理信号，但是，这个bash进程会fork一个子进程，从top中看起来不够干净。