感谢楼主为我等刚起床的海外党提供索引

没关系我还有502

@bellchu 尼玛………

500

我就是要500！

500我的啦！

@gameliving 那剩下的给谁了？
还是说CLOSEWAIT？
CLOSEWAIT只能调低timeout，因为这是内核设计

答案2属于脑筋急转弯，窃以为不算答案，真要这么实现早被内存玩死了
答案1的汉诺塔属于正常人第一反应

nginx反代加缓存不也是一样效果？

短期看不出，长期就知道了

乱七八糟瞎问，其实自己也不知道该问啥

@khan 是的
所以如果运气好，尽管调用了系统调用，申请释放，但系统还没有释放（有性能因素不是立刻释放），那么地址还属于这个进程，则会出现访问混乱。
如果操作系统已经释放了内存，就会segfault

@gameliving 按4楼的做法，kill父进程，可以温和一点，SIGTERM
几十个子进程不是问题，问题是父进程没有帮子进程释放资源。
这时候只能kill父进程，让init处理

@datocp cron每分钟加一条iptables规则这算几个意思？

location ~* .*\.(gif|jpg|jpeg|png|bmp|swf|js|css) {
}

location不带get参数

照理说，进程结束后，所有未关闭的文件句柄会由父进程接手，最后由init释放。
tcp sock也是文件句柄。
是服务死了但进程还在么？
还是父进程没处理？

@khan 嵌入式编译器比如sdcc，因资源有限，会默认静态分配所有变量，类似static（但未明确声明static的可能被overlay，即不保证数据保留）
要可重入，实现的时候就要在栈上分配变量，而不是在编译的时候指定内存地址，这就是区别。
对嵌入式系统来说，受限于指令集，栈空间通常不足，所以不得已为之
正常PC平台的编译器没有这个问题，上述只是特例

@khan 所以我说可能Segfault。主要看这个地址是否还属于这个进程。
访问空指针当然是要死，但是free是可以的。

@GeekTest 要在大量接入的前提下还能达到这个速度，硬件投入不低啊