@01802 哎，头大，我应该直接买这个好了，回头卖掉我这个东西，买你这个吧😂。主要是手上工具不够，思路还是没问题的。散热应该是抽风负压 才行，搞错了。。

@linglin0924 哎，真的太惨了。5W 确实挺难受的，都是打工的。主要是心里难受，要是对方啥 困难的，倒也是好说，换了 2 套房，别说了，开干吧。先通知他们，去拜访他们，然后在一家亲通知，不行就法院见就可以了。

别问了，直接送他 16w ，你要是搞担保，以后大把问题。还有你借出去，就不要指望还了，10 年 8 年都还不上给你。哎，自己看着办吧。

@Autonomous 嗯，先用着吧，无所谓了，问题不大。先观察个把月，因为我自己的要存放的东西其实不多。

咸鱼一大堆，经济又实惠，干净又卫生。放心吃，新机器，个人 商家都可以入手。

@sidkang 是挺尴尬的😄
@imsoso 内网带宽吗？我 wifi6 基本能跑满内网 nas 的 1Gpbs

ipados 能安装虚拟机，😋，还要啥生产力，或者内核开放虚拟机接口，或者能兼容运行 macos 的软件把。当然早点睡觉，做梦会更快实现。

可执行代码：

```
@PostMapping("/test")
public void postUrl(HttpServletRequest req) {
final AsyncContext ctx = req.startAsync();
List<String> respList = new ArrayList<>();
int taskNum = 10;
CountDownLatch countDownLatch = new CountDownLatch(taskNum);
for (int i = 0; i < taskNum; i++) {
VertxHttpClientUtil httpClientUtil = new VertxHttpClientUtil();
httpClientUtil.post("https://baidu.com", (resp) -> {
respList.add(resp);
countDownLatch.countDown();
});
}
CompletableFuture.supplyAsync(() -> {
try {
countDownLatch.await();
System.out.println("finish..");
ctx.getResponse().getWriter().print(respList.get(0));
ctx.complete();
} catch (Exception e) {
e.printStackTrace();
}
return null;
});
}

```
CompletableFuture ，请自行设置 50-200 个线程，瓶颈在于 CompletableFuture 的线程数和你第三接口的吞吐量了。

你可以看看我的答案，完美符合你的需求。https://www.bilibili.com/video/BV1FS4y1o7QB ， 用 tomcat 的 NIO ，异步 servlet api ，完全没压力，你个机器单机 1000/s 吞吐量都可以。客户端找一个响应式的，或 vert.x 生态的也有，我代码给出了例子。不要先判断对错，要先看。看完，就会明白。当然 CompletableFuture 。allOf 也得用上，不然不好控制多个任务的同步问题

@kukat 😄，有信心，因为自己操刀的。而且群晖系统牛皮，只要硬盘在问题不大，换 U 盘启动，换主机迁移，我都测试过没问题，妥妥的稳。

@Cassius 这个好，非常的硬核，非常的全面，非常感谢。后续我看看是否要换 12V-ATX 模块。

咸鱼直接买 R4S 吧或者 R2S 。或者搞旁路由，我的就是旁路由，你直接虚拟机跑一个，旁路由比较好玩。

@geniussoft 我应该想错了，不需要继电器，直接连接备用锂电池就可以了，只要加一个二极管隔离就可以了。后面电路图画好，请教下你。

@geniussoft 那有什么其他的好方案，可以介绍下吗？因为我的电路的知识很有限。

@geniussoft 嗯 你这个解释我能接受。切换的电压曲线，我可能搞不定，我没示波器。但是我有大电容可以提供秒级的电压， 不会有欠压情况，继电器切换开关在 30-60ms ，固态继电器的就更短。而锂电池可以提供半个小时的电量。你电路高手啊，你应该可以设计出这样的备用电源的电路啊，从理论出发是完全没问题的。这么简单的电路设计，闭着眼睛都能画出来吧。

@ruanimal 有可能，但是印象中是有过一次震动，大部分情况都是放沙发。

@geniussoft 。。。这论据是啥？这个 nas 主机的可靠性可能是差了一点点，但是放角落不动，没啥大问题，散热可以再优化。至于 UPS 是可行，因为我有验证过，你的论据是啥？

@codefever 之前散热不行，拷贝东西都死机了 ，现在的散热估计还有待改进，现在深圳 23 度，硬盘待机将近 40 度。拷贝 10 分钟，硬盘温度会去到 50-60 度，如果不是高强度应该可以，而且目前只有 3 个硬盘还行。。。。夏天到了再看看后面可以再优化一下，

@Jekins 可以看看那个 B 战-小巫老师，视频：NIO 场景和实战，有很多场景和代码验证。还有一个 NIO 服务的绝对优势，看完你就知道小白的问题在哪里了。里面还有一个多线程的讲解，也有代码验证 《最大线程数计算公式》的例子。大多数人都不知道怎么去理解 NIO ，他们以为 用上 tomcat 8.x 后的就以为用上了 NIO 了，实际上还差一些。

@xxfye 正确，回答正确。tomcat NIO 要开 200 个线程，那是因为业务层“一般”一般一般依然使用阻塞模型，如果使用异步模型，那么只要少量的线程即可，但是需要使用者去主动设置。

关于网上说的：bio 上下文竞争比 nio 强烈 。因为 NIO 一般只需要设置等于 cpu 核心数即可，BIO 需要设置大量的线程，所以结果是：bio 上下文竞争比 nio 强烈。因果关系没搞明白吗？

如果你想测试多线程开销到底有多大的影响，我代码中有给出例子，你可以使用 TestMaxThreadNum.calculationCpuTime() 去验证，第一次设置 cpu 核心数量，第二次设置 2000 个线程，你就会发现 2000 大量的线程 跑起来没有线程数量少的快（ cpu 密集型情况下）。所以 ”线程数量多“ 的上下文竞争 会比 ”线程数量少“ 的厉害，性能会有所下降。

另外 BIO 上下文竞争是否会比 NIO 厉害，这里要区分情况，如果 BIO 线程中经常出现 IO 等待，那么不会有特别多的线程竞争。只有在 IO 时间短，且存在大量的线程的情况下，才会出现这样的情况。要减少这种情况，就需要在业务 IO 时间短的时候，使用少量线程，这不好设置和判断。而 NIO 则可以无视 IO 时间，我在视频中有讲过。

能救一个算一个。

@Leviathann tomcat 问题不大啊，你应该看看我的那个讲解 会给你展示 tomcat 如何处理高并发的场景，不是它不行，而是大部分人不会用。它 tomcat 也是支持 NIO ，使用 servlet 异步编程，依然可以少量的线程，处理高并发。b 战：小巫老师的 NIO 服务的优势-无视 IO 时间，tomat 单机跑 1w+/s 的 QPS 也问题不大。

@zmal 是的，我已经给 OP 的测试方案了，希望他能研究学习下。
@relaxchen mongodb 不是内网部署吗，相对安全把？被批量扫库是什么意思？
@lisongeee 即便 OP 能拿出数据来，也可能是错的，因为测试的方案就不正确了。

我那个视频有讲解怎么做正确的压力测试的，一般用 jmeter 测试没问题，但是测试 NIO 就需要换一个，可以使用 ab(ApacheBench)和 wrk 压测工具。如果知道 http 协议 那么就应该知道 连接数 是关键因素，但是太多人不清楚了。。。jmeter 适合测试 BIO 的服务，不适合测试 NIO 的服务，建议用 wrk 这个工具。

@jeesk 哈哈，先看完，如果有问题可以留言或者 加绿色。我已经给你答案了，还有很多测试的代码，可以验证你的疑虑。为何 tomcat NIO 等于没用？因为下游的业务代码全是阻塞 IO 代码，所以你才会看到 tomcat NIO 依然需要默认 200 个线程。而 webflux 默认就是 cpu 核心数的线程，因为它是响应式编程。除了 webflux ，还有一个 vert.x 使用异步编程，也可以做到少量线程。当然你的业务如果是阻塞 IO 的操作，比如 mysql 读写等，还是需要创建的线程池去处理。

作为一个后辈，我是需要你做出指引，给大家做出指引，科普知识非常的困难，我尽力而为。当然你说的推广算是附带的吧。