@westoy 他那个独立开发，应该是 接 300-1000 百块的学生定制作业。我接过，有时候累，大多数时候简单。你提的这个建议还是挺好的。再过几年，我也试试跑下业务看看😄

5800H ，16G 板载，2100 即可抬走把，来吧超值哦。

不要买 mac mini, 做研发就用笔记本，因为有触控板，用了触控板，你就知道为何苹果那么牛。windows 预计还有 5 年才能追上来。只有小部分能追上来。触控板很好用。丝滑。不过笔记本的键盘我表示一般般

50 包邮吧，把能卖的东西都卖掉，只留下手机就好了。把 macbook 卖掉，或者把屏幕卖掉，留一个就可以了。把房间的东西都精简一下

@dearmymy 我丢，这个绝了😄。但是借钱 估计更麻烦把。。

@ZE3kr 不会吧，我记得这个上下左右键有改变的，所以肯定不是一套库存用 6 年。很多人说库存，我感觉不是，我猜苹果是做了市场调查 做出选择的 。按苹果的实力做的相对精准的库存应该没啥大问题。但是这样世界存在很多偏见，全是自己的想法，按自己的需求去做出错误的判断。也许国外的很多人就是喜欢 13 寸的 pro 呢。还有说 touchbar 就更无语的，我也用过，我也是开发，我觉得还是挺好用的。不少的应用都适配了，idea 也适配了。但是 到部分人的手里，全是缺点。

@WOLFRAZOR 你不要害怕，你要相信科学，做一个爱科学的人。cpu 设计的时候 可以很耐热的。我的 M3 6Y30 打开浏览器就 90°+了，一直忘死里干它，别怕它，不要害怕发热。要相信科学。air m1 还很强的。昨天长时间跑程序确实干到了 80°，但是大部分情况下都是 35°-50°，所以不要害怕。

支持 AIR 一个，你确定是一个轻量使用 macbook 的场景了，那么 air 最合适了。当然建议不要买，继续用 intel ，或者 air m1 也可以，便宜实惠。

@wsseo 不行的，因为基因，人的生长环境决定了企业的基因。华为肯定走着走着就会走歪，急功近利一定是会发生，基因是无法改变的。即便走的很顺利，走到了苹果 5 年前的生态规模，依然不行，各种猪头操作会诞生。基因难以改变。

星际蜗牛 350 到手即可用了，赶紧买把。另外实时解码到底是啥场景啊？买个 N1 搞定？除了老旧的电视机，还有啥场景需要硬解码？搞 N1 把

@czd670 呢可以的，建议用线程池去 执行同步 IO ，这样不会损失太多的性能。

@czd670 是的，需要用 r2dbc 。 “我的理解是，在 webflux 里面，非阻塞只应用在接受请求发出请求。数据库操作，我还是在工作线程里面使用阻塞 io 也是可以的吧？” ，不是很理解你表达啥。工作线程 使用阻塞 IO 是不行的。性能会严重 下降

@jlak 8G 轻量办公可以，16g 确实比较合适，因为浏览器吃内存多。你应该不是开发吧，不然很多人推荐你上 64g 。

去咸鱼买就可以了，你就能得到你想要的东西了。苹果的东西可以 在咸鱼买的，因为有全国联保的。

@CEBBCAT 是的，客户端程序 BUG ，嘿嘿
@Chisel 他们传输协议 不是 HTTPS 吗？有啥问题

第一个问题：使用数据库操作必须是 非阻塞的， 有同步非阻塞和异步非阻塞，都可以。这些异步库 操作磁盘 IO 没听明白。这些数据库的异步库代码一般都是网络 IO ，应该不涉及到写磁盘 IO 。
第二个问题：本质是 NIO ，用 NIO 客户端。

第三个：但是 mysql 的通信协议 可能不支持多路复用（我没确认过），这里的多路复用是指协议上的多路复用（非 NIO 那种概念）。这个多路复用，就是在一个 TCP 连接中可以存在多条流。http2 支持多路复用，http 不支持。也就是说即便用上 NIO 也未必能带来更大的吞吐量，需要同时调整 http 连接数。同理 mysql 也可能会在连接数出现瓶颈。请求的数据可能会堆积在服务端。

第四个，由于是响应式编程，注意下背压的问题，保护好下游的服务。

少年，一个分布式锁就可以解决了。另外你这个为啥不是做负载均衡，而是做 HA ？

@frank1256 对了 解决的办法是：任务等待队列适当增加，一般按能接受的任务执行时长来设置。如果很大，意味着后续的任务可能要排队很久才会被执行到，好比去银行排队，前面都有 1000 人 ，实在没必要排队。这个时候应该抛出异步，早点暴露出当前线程池不足的问题。而你的这种情况 新增任务太快，可以适当延迟 1-3ms 的新增间隔，让线程池有时间去取队列中的任务即可，或者设置队列长度 5-10 即可。你这种情况毕竟比较极端的测试，实际场景较少。keepAliveTime 也还好，10-60s 都可以，跟任务并发吞吐量 的变化有一些关系，一般不是特别需要关注。0 的话太极端了。

因为核心线程数设置了 10 ，跟最大线程数 10 一样，因为内置的线程池实现是默认不初始化核心线程数的（ apache 默认初始化核心线程数），所以第一次时候，全部使用创建新线程执行 10 个任务。

到了第二次之后，任务来了之后默认存放在队列中（因为 corePoolSize 已经满了），但是这个时候太快了，线程池还没来得及消费这个队列任务(还没拿走这个任务)，就满了（而且最大线程数也等于 10 ，也满了），导致触发拒绝策略。我也纳闷为何不直接拿核心线程去执行呢？因为去拿核心线程执行，还需要判断这个核心线程是否空闲，那不如直接丢到任务队列里，核心线程有空闲就直接去拿就可以了。

尝试调整参数，调整 corePoolSize = 7 或者 8 , maximumPoolSize=10 不变，还是不行。前面 10 个任务正常处理，但是到了第 14, 15 个依然不行。虽然 keepAliveTime = 0, 但是还没来得及释放线程，就会出现问题队列塞满的情况，corePoolSize = 0 或者 1 ，就可以正常执行，因为来得及释放线程，后续的任务依然可以新创建线程来执行。

这种极端的测试还是挺有意思的。可以先了解下 线程池原理，因为很快找到问题。

刘海人类历史上 又新增一个丑的东西。别说 720p 够用，480p 都够用了，能看清是个人就可以啦。乔老爷 真的盖不住了。新增这个玩意，估计系统 UI 的设计都扭曲不少，应该有一堆冗余的 UI 代码，头大。