Golang Go语言中文件夹监控的通讯方式到底让什么资源瓶颈了？
大概架构是这样，A 进程监控事件，然后产生图片到一个文件夹，B 进程监控文件夹，并记录生成的事件，其中涉及到转换 bmp 文件为 jpg （源图太大）,实际操作过程中，经常会出现图片丢失的情况，或者说源图产生但是图片是空，然后并发高的时候整个进程都很卡，ctrl-C 要好久进程才能结束，卡的时候甚至 ssh 都登录不了，第一次碰到这情况，咋回事呢？
Golang Go语言中文件夹监控的通讯方式到底让什么资源瓶颈了？
卡的时候其实 ls 命令也要卡半天才会出结果
更多关于Golang Go语言中文件夹监控的通讯方式到底让什么资源瓶颈了？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
做开发要经常检查 CPU 使用率、io 负载、网络负载等。
你这种架构需要限制最大事务数量，超过的直接丢掉，或者改为多级架构。前级只做 path str 处理，后级再根据整机负载，慢慢处理图片。
我之前用 go 的 fsnotify 实现监听文件功能的时候，也遇到过使用 CPU 太高的问题。后来的解决方案是加个定时器，隔 10S 再批量处理一下事件，CPU 使用率就降下去了
https://github.com/gohugoio/hugo/blob/387c5f60f97141d638327f84ee426fb44f6c554e/watcher/batcher.go#L60-L78
hugo 中有个 batcher ，也是类似的思路。批量汇集事件之后再处理。
#7
改进之后，监听的目录没有 exclude node_modules, 监听了几万个文件，也没有太大的性能问题。
但我的逻辑很简单，监听到文件修改之后发个 http 请求，没有你的逻辑复杂。
作为IT领域Go语言方面的专家，对于Golang中文件夹监控的通讯方式及其可能遇到的资源瓶颈，有以下见解：
在Golang中，文件夹监控通常通过fsnotify库实现，它提供了一个基于channel的、跨平台的实时监听接口。然而，在实现文件夹监控时，可能会遇到一些资源瓶颈。
首先，I/O操作本身就是一个潜在的性能瓶颈。监控文件夹涉及频繁的文件系统访问，如果文件系统响应缓慢或监控的文件夹数量众多，可能会导致性能下降。
其次，内存分配和垃圾回收也可能成为问题。fsnotify库在内部可能需要分配一定的内存来存储监控事件和相关信息，如果内存分配频繁或垃圾回收不及时，可能会影响性能。
此外，并发控制也是一个需要考虑的因素。如果多个goroutine同时访问或修改监控对象，可能会导致竞态条件和数据不一致的问题，进而影响性能。
为了优化文件夹监控的性能，可以考虑以下措施：
- 使用异步I/O操作来减少阻塞。
- 通过对象池等技术减少内存分配次数。
- 谨慎使用并发控制机制，避免不必要的锁竞争。
综上所述，Golang中文件夹监控的通讯方式可能受到I/O操作、内存分配和垃圾回收以及并发控制等资源瓶颈的影响。通过合理的优化措施，可以提高文件夹监控的性能。
