f1 :: A -> B
f2 :: C -> D
f3 :: B -> D -> E
f4 :: E -> R

let b = f1(a)
let d = f2(c)
let e = f3(b, d)
let result = f4(e)

直接把业务依赖编码进类型里不就完事了？

@haimall 无差别打击了，别人晚上载着老婆孩子回家，碰上你教唆别人放的钉子出了车祸，你负责么？

1. 我提的 byd 宋 dmi ，满油续航一千多公里，我看 M5 续航里程也差不多
2. 想要蓝牌的话可以拍，听说新能源车也可以上蓝牌，而且蓝牌跟人走，万一哪天新能源政策没了，你的车牌还在手里。

混动满油一千多公里续航，完全没有里程焦虑

BYD 汉 DM-i 可以考虑，万一运气好自燃了还能免费换新车😂

我宋 DM-i 刚提车，跑通勤+周末城镇高速，亏电百公里不到 4L

一篇屎上雕花的美团八股文，你已经换着花样发了 10 贴了。未来是协程的天下，动态线程池没有活路的


旧评：
别动态线程池了，还不如把 CompletableFuture 用对用好，动态线程池纯粹是先把代码写屎，再在屎上雕花的不必要方案。
JVM 往保守了说有 fiber ，CompletableFuture 可以用，往激进了说还有 kotlin suspend ，展望未来还可以上 loom ，不管哪条路都没有动态线程池的活路。

@ligz 如果你是用 minikube 教学的话，体积更不是问题了。
就算是在云上做练习，EKS 或者 Aliyun ACK ，都可以推到自己私有 registry 里去，毕竟 dockerhub 能成功拉取看运气，运气不好一个 pause-amd64 也能卡两个小时，这家伙可才 300kb

@ligz 内网都是千兆宽带，百兆镜像都是秒 pull ，基础镜像和没变化的 jar 都在前几层 layer ，hash 不变更快
并且 graal 的 native 很难做教程，java 到处都是反射。

总之：java 版很容易，那点体积在内网 registry 不是问题。native 不值得

从完备性角度讲 object 的 key 顺序也是信息
当然一般业务开发中应当避免依赖顺序，如果需要在页面展示 table column ，也建议在对象内放一个排序或权重值。

才 1000 次，说白了就是 1000 次 mul + add + mod ，暴力算也不过几微秒的事，这还要什么优化？
就算是一百万次也不值得优化

现役 1000XM3 用户
还用过 900N / AirPods Pro / 1000XM2 等，不差钱建议直接 AirPods Max ，差钱建议 1000XM5

你们有 Scala 业务？

上班要求穿西装么？

毕业后才开始学英语的表示，你想学什么时候都不晚。亲身经历：

2012 年大专毕业时词汇量大约 400 个吧，我上学那会儿就喜欢背一句诗“堂堂正正中国人，为何要学英国文”
还傻乎乎的认为未来机器翻译会发展到能替代人类翻译的程度，直到从事了机器学习相关行业后我才知道，这一目标有生之年都不可能实现。

毕业后我硬是靠着机器翻译啃英文文档度过了开始的 4 年，积攒了大约 1500 词汇，其中绝大部分是编程语言关键词和技术术语。

2016 年决定要把英语补回来，买了套初中英语教材，从初一开始看，看到初中毕业熟悉语法。后来自己在百词斩+扇贝坚持背单词，2020 年左右我词汇量已经接近 1 万了。

2021 年开始发现虽然我词汇量很多，但是不经常用遗忘的也很快，不懂语法依然啃不动 medium 技术文章。然后我开始看 Youtube 视频，开着字幕连快速阅读，慢慢的关闭字幕练听感。

我知道我英语水平和 V 站平均水平没法比，但至少看英文原版技术书籍和听技术演讲已经问题不大了。我的补救路线楼主可以参考一下

一般对于缓存问题，我都会先问一句，缓存服务是必须引入的组件吗？
你的业务量在可预见的未来，会增长到单机数据库难以支撑的程度吗？

然后问第二句，你是否真的理解 CAP 。不要试图去挑战 CAP ，这里面水太深，你把握不住。

据我观察除了头部公司几个流量业务外，99% 项目的并发量直到项目死掉都没有超出单机数据库的承载范围，引入 Redis 对你们是否真的有必要？

如果真的有必要，请熟读 1 楼帖子

没用过 async-db ，r2dbc 等方案，只用过 hikaricp 链接池 + 异步的响应式。我说下我的经验：

事务：因为背后还是 jdbc ，所以事务必定发生在同一个 jdbc connection 当中，业务编码的时候会把整个异步代码块打上一个 transaction 标记作为边界，表示在边界内的 sql 都处于同一个事务中。

一致性：和传统并无二致

性能提升：业务代码部分只需要一个 n = cores 的线程池作为纤程的运行时就够了，所以几乎没有上下文切换。jdbc 部分都交给 hikaricp 管理，iowait 的线程对操作系统没什么消耗，可能会在跨线程（核心）数据交换上会浪费一点资源，但和传统阻塞式比可以忽略不计了。所以首先要满足的条件是你自己的应用也需要遵守响应式开发，不然的话可以说没有性能提升。

别动态线程池了，还不如把 CompletableFuture 用对用好，动态线程池纯粹是先把代码写屎，再在屎上雕花的不必要方案。
JVM 往保守了说有 fiber ，CompletableFuture 可以用，往激进了说还有 kotlin suspend ，展望未来还可以上 loom ，不管哪条路都没有动态线程池的活路。