fakevam

clangd + youcompleteme +vim

win7 x64 就有 patch guard 了，绕过 PG 的方案有很多，但是出一个死一个
一定要做内核防护的话，内核提供了很多 callback，可以驱动注入去做 callback 检测，但是点比较少，比如 object callback

另外，还有一条万能的路，走虚拟化，在 host 上 hook vm，参考 360 他们的做法

当然，你可以把 PG 关掉，这个方案搜一把就一大堆了

意思就是说，内核很多报错，不是所有场合都和你理解的那个 errno 的字面意思一样

NO space left on device 未必是真的 no space left，可能只是某个抽象资源用完了

no mem 也是一个意思

因为内核资源耗尽，统一返回 NOMEM，这个 errno 的语义不限于 MEM，一般是指某种资源

举个例子，你设置 cgroup，如果没设置 memory 允许的 numa node，直接去设置 cpu 的列表，也会返回这个 errno

@baoyexi 补充一点，lock-free 对于 99.99%的代码来说是屠龙之术
一把锁只有没有办法降低冲突了，才会考虑 lock-free，否则优先考虑怎么避免冲突

@baoyexi
mutex 这个东西不要想着去优化锁本身的性能
1. 锁内部的代码，是否足够轻便和必要
2. 锁冲突的路径是不是可以考虑转移，把锁转移到一个数据流更加冷的路径下去

@Lime mutex 自己做的成本很高，这是我不推荐用协程的关键原因，因为没有人知道谁会怎么跑你在你的任务框架上，协程的锁理论需要做锁膨胀才是最优解

调度饥渴就是调度公平问题，考虑一个很经典的场景，N 个人去 xxx 部门开证明，有 M 个步骤，每个步骤都需要串行，最后的结果就是第一个人处处优先，最后一个特别慢，明显这种情况下，最后一个人可能是很不满意的
内核的 cfs 调度其实某些角度就是为了解决这个问题，epoll_wait 的 event，也可能导致类似的问题，我只开个头，你自己思考

1. mutex 的实现太暴力了，有些场景会很糟糕，怎么退化 mutex 是需要考虑的，退化 mutex 以后这个问题就复杂化了
2. 调度优先级也过于暴力，考虑性能比较多，考虑公平性不够，可能出现调度饥渴，另外 task 的亲和性问题貌似没看到太多的处理，计算敏感的场景下，task 的亲和性还是很重要的
3. 准备下配套的 gdb 调试脚本，否则切换协程以后压根没法调试，不是每个人都会去解析那一堆的上下文的
4. 一个 epoll 大概率是不够的，epoll 在某些场景下性能退化很严重的，有些东西比较糟心

抛开这些，代码质量还是不错的
不过我还是不推荐玩这种东西，受限太严重了，需要性能的时候，一切都需要自己控制，不需要的时候，golang 的那套足够覆盖了

监控本质是解决问题的，如果说监控解决不了问题，只是为了做一套完整的方案而做监控
那么监控的意义是不存在的
普罗米修斯那套东西之所以只是基础设施，就是因为他没有办法去解决业务上的问题

这就是典型的把手段当做了目的，我做了监控，我的任务完成了，但是其实任务的核心是——解决线上已经存在的，或者可能存在的问题，聚焦没聚焦好

所以吐槽和被吐槽的同时，不妨思考下，自己做的东西到底解决了啥问题，而不是，我出于好心，所以需要有好报

监控的核心在
1. 什么数据值得采集
1) 业务、内核 软抽象资源，比如文件打开个数上线，tcp 的 backlog
2) 通用硬件资源的抽象，比如 cpu 内存 io 带宽
3) 服务质量抽象，比如各种请求的延迟，队列长度
4) 各种错误的感知，各种事件的感知，比如 java 触发了一次 gc，操作系统触发了一次 recliam，业务触发了一次 xxx
2. 数据的采集成本是什么
xxx 数据读的成本是多少，比如 win 下的 createsnapshot 成本有多高，适合多少秒采集一次，linux 下遍历 /proc 的成本是啥（ proc 可不是真的内存文件）
3. 怎么呈现数据让人可以快速找到问题所在，这里的核心是怎么整理排查问题的思路，让有关联性的数据在一起，但是不能乱做时序上的关联