@YuiTH 我基本上常规的用用快捷键，其它复杂的都是鼠标点点点，也没觉得麻烦多少。可能这就是我至今都不喜欢 vim 的原因吧。另外我不用 rider 的原因其实是因为 jb 全家都没有 peek view ，我很喜欢这个功能。

我觉得 1234 都是心里习惯，需要适应期。就 C#而言 vs 的调试功能绝对是比 rider 强，vs2022 我是没有用 resharper 的，虽然我机器 64G 内存但是不知道为啥还是卡成狗。但是我觉得 vs 自带的也够了，这几年 vs 的功能升级也让 resharper 不是那么刚需。

既然你不想要异步，那并行流和线程池没有区别呀

@nothingistrue 异步和同步和你用什么处理没关系。准备读取数据的时候数据已经复制到用户缓冲就是异步，否则是同步。线程池那些都是后话。

@jeesk 浏览器的 js 一直都是单线程的，你总不能说 worker 算多线程吧（

@lmshl NIO 是同步非阻塞，并不是异步。

@jeesk
你认为的几个谬论，实际上都是你自己的理解有些问题。
1. 如果无论是 BIO 和 NIO 你都用 200 线程，确实线程之间的竞争都差不多。但是这里你的问题在于如果用 NIO ，我们使用的线程数量不会是 200 。通常 IO 线程数量选 CPU 核心数 * 2 ，或者再 +2 。比方说如果是四核心，那就是 10 线程左右。
2. Java 的默认线程栈大小就是 1MB 这个其实没什么好多解释的。BIO 比 NIO 的内存消耗更大的原因其实就只是 BIO 需要更多线程。
3.1. 这里其实还是和 1 一样，NIO 使用比 BIO 更少的线程所以内存消耗低，而不是线程池限制了消耗。当然 BIO 下你也没办法用线程池，因为每个连接都会独占一个线程。所以说线程池减少了内存消耗不准确。
3.2. 这里的占用线程指的是操作系统对于线程分配的时间片，不过这里 BIO 和 NIO 一样都是内核等待所以确实是没差别。

你这个描述给我的感觉类似于不知道电锯怎么开然后抱怨砍树不如斧头好使…

@yuangee888
这种基本不加密，因为加密也没啥用。不管你怎么混淆最终这类东西还是要连接远程数据库然后抓个包就啥都有了。这种古董程序连接也基本不会有 mTLS 保护，所以别考虑这么多，随便用个 AES 然后把密钥丢 C 里用 PInvoke 一下就行了。防君子不防小人。

我的 jcb 卡到了，绑日区没有问题，看来可以入新机器了。

@Donahue
好吧我没考虑二手。但是 b450 也太惨了吧，至少 550 吧。而且 1T 不好分，还是 512 加 1T 更适合。

4k 感觉有点低，板 U 就划掉最少 2500 了。剩下怎么都凑不够感觉…

@FrankAdler Java 一般都是诟病其内存消耗大，很少会说性能差。JIT 理论上至少能和 aot 齐平。

@atfeel 你这个看起来根本不是 uloing 的问题而是 x86 上你读取的这个值他压根不是 64bit 的。

所以你们还是老老实实考虑升级吧，现在几乎没有 1.12 这么低版本的东西了。。。

那为啥不用 ceph 呢，直接 rbd 不是更简单呐

另外为什么不用更简单的比方说 longhorn ，为了存储和 k8s 分离？

你这版本也太老了！

Heketi 都快不维护了你选啥不好选这个。。。