guyeu

都有服务端了，那肯定是有客户端的，在已有客户端的基础上封装一套 bot 来跑压测并不复杂。
我比较想知道 TCP 的话就不是 request-reply 那种消息模型了吧，传统的响应延时这种指标就不太好使了，你们用哪些指标来评估服务器的性能表现呢？

@diagnostics #50 默认情况下一个 runner 同时只会执行一个任务，所以不会出现任务之间互相影响的情况。速度的话，Linux 上的 docker 和 Mac/Windows 上的 docker 不是一个物种，具体情况还是要具体分析。

@diagnostics #46 gitlab 的 cicd 并不是必须用 docker 跑，gitlab-runner 支持很多种环境，而且允许用户自己注册自己的 runner 。docker 跑也不见得天然比 Jenkins 慢一个数量级。。。

release 的 ci 和 merge request 的 ci 可以用 rules 区分，rules 支持的规则就很多了，分支、事件源等等。。。这方面 Jenkins 使用的 webhook api 是很难和 gitlab 本身比的。

写 Kotlin 、Scala 和 Java 甚至还带点 C++的混合项目，用了 gradle 已经回不去了

1. 多模块的支持比 maven 好，虽然 maven 有优化这方面的计划，但随意增减模块不用先`mvn install`就可以成功构建体验感会好一些；
2. 增量构建在日常开发中的加速效果明显，如果你不用 IDEA 这么高级的东东，随时修改随时编译随时允许 UT 的体验感 maven 是比不了 gradle 的，如果用了 IDEA 这种高级货，那么 IDEA 的编译和 maven 的编译是基本上是冲突的，IDEA 编译会破坏 maven 的编译，两边就都没办法“增量了”；
3. 项目越花哨，对构建脚本的功能性要求就越强，就势必要自己写一些扩展，这方面 gradle 很容易，简单处理的话直接在 build.gradle{.kts}里写函数就好，但是 maven 就复杂多了，基本上都得新建项目（另外，现在 gradle 支持 Kotlin ，有 Android 开发经验的同学几乎没有上手难度）；
4. 依赖的管理，用 maven 的话，有一种操作是在 pom.xml 里定义许许多多版本号的 properties ，然后在各种地方用，但是没办法跨项目用，gradle 有一个更优雅的搞法叫 versionCatalogs ，写一个 TOML 文件之后可以把它导入到各个项目；

然而 maven 这种完全声明式的构建机制是最简单，人类读起来也最没有心智负担的，如果项目的复杂度没有到一定程度，maven 就是最棒的（虽然 gradle 也在发明自己的声明式 DSL ）

Vertx 的下一个大版本就有 @ProtobGen 了，这个不会干这种奇怪的事情

Conan 可解你忧

@284716337 操作系统，文件系统是什么？

你的目的是不要线程池阻塞？这里的阻塞不是一个很清晰的表述，假如它是指避免一个任务长期占用线程：
1. 对于计算密集型任务，唯一实际可用的办法是在逻辑里去检查线程的内部状态然后按照业务去处理（早期版本可以用一个叫`Thread.stop`的方法来暴力停止，但这不是一个生产可用的选项）；
2. 对于 IO 密集型任务，合理的实现都会响应`interrupt`信号，因此`cancel`方法就足够了。

实际上，更常见的需求是避免任务堆积导致内存压力，这种情况下：
1. 限制阻塞队列的长度，并设计合理的拒绝策略；
2. 解决资源瓶颈，缺 CPU 就加 CPU ，缺消费者就增加消费者节点。

```shell
truncate -s 0 /path/to/logfile
```

:(
依然搞不明白 V2 评论区咋发源码。