并不是，大部分还是比较相近的专业，例如软工、通信、自动化之类。生化环材一个也没遇到。

没有图，有也不能放。这不是什么严谨的结论，就是个人的一些感觉。

这个数字很保守，实际我面试的人里面应该超过90%了。

多谢指出，已修正。具体的压缩比根消息内容和一批消息的大小有比较大关系，在我们的场景压缩比能到7:1～10:1，快一个数量级了。

1. 没有绕过tcp流量控制一说，写这个文章一个原因是高延迟带宽对传输速率的影响这个应该很少有人注意到（我也是第一次遇到这类问题），跨机房的传输速率只能到那么高（而且费用很高），所以合理的方式就是降低传输量。
2. 压测就是模拟的生产的某个业务场景，消息体的大小是一个很关键的参数，这个是从生产环境统计了一部分消息获取的。文中提到的优化肯定是都应用到了生产环境的。
3. 别的解决方式，增加并发度方向：可以增大Kafka partition数量，但是不是越大越好，有一定的副作用。进一步减少网络传输量考虑：可以使用更紧凑的数据格式，例如pb，但是这需要在consumer端做一定的开发。

qps到几千的规模，考虑用wrk吧。

赞一个，之前也想也写一下我的实践过程，觉得这篇基本把我要写的都写了。
静态扫描不是简单的引入一个工具、部署一下就完事儿的，这也是这个文章的优点，写了一个完整的技术topic实践过程。

补充几点：

1. 多分支支持是sonarqube的收费版本的特性之一，但是社区也有开源插件支持，比用多项目区分效果好一些。
2. 规则集的选择不仅要考虑问题等级，还要考虑业务特性，比如有些业务比较在意安全性，可以把安全相关的规则都加上。
3. 除了Jenkins，还可以尝试一下gitlab ci，这种方式接入成本更低，体验更好。有插件可以直接把问题展示在commit页面，对研发的体验更好。

理论上有可能，但是实际上会有很多问题，就文中的例子，有打出堆栈，代码也是开源的，当时我们很多人定位这个问题，包括熟悉该框架的算法工程师，都没有找到原因。再举个例子，美团技术博客的文章：https://tech.meituan.com/2018/10/18/netty-direct-memory-screening.html ，之前也找了不少资料，个人觉得Java的内存泄漏很难做到仅凭堆栈就一目了然，不如你给个例子？

多谢指出问题。

1. 你说的对，但是似乎原文没有体现GC一定有问题的意思，如果有请指出以便修正。
2. 实践了一下top -H看到的线程的内存信息和进程一致（同一Java应用进程的程的内存信息一样）。实际上当时面对的问题是CPU使用率报警，并不是一开始就知道是内存问题。另外“Jstack 找到有内存问题的线程然后再看干了啥”，具体是指什么呢？

1. 看的很细心，是有点问题，原因是这样，报警的是线上服务机器是8C的，当时持续时间较长，而且服务是混部的，为了整体服务稳定，让op手动重启服务了，所以没留下现场信息。后面的截图都是线下测试环境重现时候的截图，线下机器配置是4C，已在正文指出。

2. 当我们说内存泄漏：https://en.wikipedia.org/wiki/Memory_leak ，其实隐含了是内存不合理的使用行为，相对应的是你提到的程序正常使用（其实两者没有严格的区分，存在一些灰色的地带），这些都是对内存使用行为的描述，但我们关注的是结果，也就是内存不足时引发的频繁GC，这回导致CPU高占用，服务不可用或者延迟突增。所以，是什么原因其实没有不重要，出现这种情况都是需要暴露出来的问题。
   然后是技术层面，如何确认造成内存高占用原因的合理性（前面提到的灰色地带），首先需要定位到根本原因，然后要结合实际情况看合理性。举几个例子：如果一个程序，为了高性能，需要大量的内存作为缓存，但是客观实际是机器没有那么多内存，那就不合理，如果内存很多那就很合理。然后看文中指出的例子，对程序基本没有好处，但是内存占用却很大，那合理性就基本没有。

Update：看了你补充的问题，没遇到过类似问题，信息不足，所以给不出什么建议。另外，我定位这个问题之前之前对Java也基本没什么了解，相关知识都是定位过程中学习的，也不是什么大佬，同样你也不用小白自居。遇到问题解决问题就行了。