@Nitroethane #8 突然发现有个致命 bug，不应该在 compressFile 函数里就把 buff 给 Put，应该在 handleEvent 的 return 语句前面用 defer 给 Put 掉

@tuxz #39 求问这是什么软件生成的图片？

其实最优解应该是根据文件大小选择最合适的 bytes.Buffer，但是 sync.Pool 不支持这种操作。如果自己手动先 get，判断 buffer 大小再 put 的话，感觉会影响 GC 导致更严重的性能问题

重构了下 handleEvent 函数。这是根据压测结果来看目前性能最好的状态：
https://i.imgur.com/0fnwGB0.png
下面是三次压测结果，测试 5000 个文件，每个文件大小在 1M 以内。第一次结果是 bytes.Buffer 和 flate.Writer 都不使用 sync.Pool ；第二次压测结果是 bytes.Buffer 使用 Pool，flate.Writer 不使用；第三次是两个都使用 Pool 。
https://i.imgur.com/qSKrrSo.png
还有一个优化点是使用 bson.Marshal 方法序列化结构体。因为对这个库不是很熟悉，用了 Encoder 之后性能直接回到解放前。还需要再研究下

@GopherDaily #6 不是，readFileEvents 方法是长期运行的，被调用很多次的是 handleEvent 函数。
其实问题出在 gzBuff 和 zw 两个变量上。这两个变量的生命周期和 readFileEvents 方法是相同的。假如随着程序的运行，要处理的文件越来越大，那么 gzBuff 和 zw 这两个变量的底层 byte slice 也会越来越大，而且不会被 GC 回收，byte slice 也不会自动收缩。所以随着运行时间内存使用量会持续增长。

@darrh00 #4 我这句话是有问题…… 不过不用 sync.Pool 的话问题还存在……

@darrh00 #1 对，entry 没必要用 sync.Pool 。不用 sync.Pool 的话问题依然存在。刚在 handleEvent 函数里加了一行，退出函数前执行 w.Flush()，也没用。
看了下代码，对 gzBuff 底层数组引用的地方只有 entry.FileContent 和 buff，但是函数开始时都执行 Reset 了，不应该还占用呀


@lysS #2 这么明显的内存单位怎么能是 CPU 的图🐶

对这玩意太熟悉了，我是搞安全的，上家公司是外企，用的就是 crowdstrike falcon 。

@xiaoding #2 Mac 上不清楚，反正 windows 上对用户来说无感知，只有后台进程，终端上没有 GUI，而且就算终端有违规操作，例如执行了恶意软件，只会静默地阻止，只有后台 dashboard 才能收到报警。

就像楼上说的，它就是一 hips，监控终端的所有流量（包括访问过哪些 IP 、所有的 DNS 解析记录、访问过哪些网站）、检测扫描文件的安全性、上传终端的所有系统日志、拦截恶意软件的执行等等。不过这玩意是真的强，能检测出国内大部分流氓软件。

还有就是 crowstrike 提供的“增值服务”，他们会定期评估客户的整体安全性，会在每台终端上运行一个一次性的检测工具。这玩意会扫描整个硬盘，看你安装了哪些违规软件，有没有明文存储密码，有没有恶意软件等等。

@Aumujun 第一，你的 defer 放在错误处理前面就是有问题。第二，我跑了一下你的代码，ioctl 调用报错，但是 close 没有问题

还有，现在都用 netlink

close 返回 EBADF 说明你要关闭的文件描述符是一个无效的文件描述符。你的代码有问题，关闭 fd 的 defer 应该放到错误处理的后面，因为如果 unix.Socket() 调用失败的话，fd 的值就是一个无效的文件描述符，你关闭它当然返回 EBADF

@guoshizhong 忘记是左耳还是右耳了，好像也是左耳。我是 iPhone11，最新 iOS 稳定版，没试过 15 。我的手机之前摔过一次，还掉进水里全身水洗过

我的 AirPods 2 也有同样的问题。而且有时候就算有电，拿出来的时候也是没声，只能都放进盒子里再拿出来

不知道你用不用 tmux，用自带 terminal 的话由于不支持 osc52，导致本地 ssh 到服务器上使用 tmux，复制 tmux 中的内容时不能自动同步到本地系统剪贴板，就很难受

北方人表示吃不惯这玩意，偶尔吃一次还好

@clrss #10 只是 beta 版更新包体积比较大吧。我 14.7 显示的更新包大小只有 140M 啊

我倒是希望能有一个做饭好吃的女朋友，不求天天做，只要隔三差五有一顿就行，我承包洗碗

@AllenHua #6 很明显，大概率就是软路由上的 iptables 配置了转发规则，把目的端口为 8080 的所有数据包都转发给了 10.10.10.1，直接查软路由上 iptables 的配置，尤其是所有表的 FORWARD 链