@JasonLaw
private int 返回入参时间距今几年(String time);
Map<Integer, List<String>> yearMap = list.stream().collect(Collectors.groupingBy(this::返回入参时间距今几年, TreeMap::new, Collectors.toList()));

treeMap 只是用来把年份做个排序，遍历的时候方便。不用也可以。

我明白你的意思了，你是觉得你的一坨 if else 代码需要比较 6 次有多余耗时？其实优化成 除 12 再分组就可以了。
而且计算时间复杂度时常数的部分可以忽略。而且大于小于这种计算在这个场景里的时间消耗可以忽略不计。

一次遍历的时间复杂度是 N 。
排序的时间复杂度是 N*logN ，排序再二分还得*logN ，你咋想的大兄弟。

写个返回 time 距今几个 12 月的函数，stream 流用该函数分组，再用 treemap 搜集。

不知道为嘛 V2EX 有一个风气，很小的需求非劝人上 MQ 上 ES 之类。

这点数据量用哪个方案区别不大。如果嫌扫表太频繁，1 小时扫一次，把未来 1 小时需要执行的任务加载到定时 job 。甚至可以把所有数据放缓存，变成纯内存操作。如果主表有写入，异步线程更新到缓存。

mysql 的 emun 蛮垃的，千万别用。
mysql 的话正常来说用 tinyint 就可以了。用什么类型更多是业务方面的考量，性能差距不大。

1L 在理。强一致性在这种场景下是非必要的，把 TTL 改成 1s 足够满足需求。

盲猜是==

op 好奇的可能是为什么纯数据实体也要用 getter/setter ，这要从 Java 的一切皆对象说起了，涉及到当时的语言设计思想，略过不表。

本质上是因为在 Java 中没有结构体这种纯数据实体结构，jdk17 的 record 也只是对象的语法糖。结构体可能在 jdk18 或 19 加入。

op 吐槽的其实都是 js 的问题。
js 最开始只是想做个脚本语言，弱类型写法多变没啥不好。结果前端发展过于迅猛，很快面临了工程化问题。js 的各种弱点暴露的比较明显。

你吐槽的东西大部分能用 js 类型补丁语言：ts 来解决。ts 写起来挺爽的。

对你说的 ygc 变慢是 intern()引起的说法存疑。

当 stringtable 里的字符串被复用的时候就节省时间了呗，intern() 不就是做这个的嘛。

技术不是银弹，和 web2 没啥关系。

需要。就比如一个目录树，新手能写个 N 次方算法出来。

如果写小程序，或者老旧 windows 平台（医院自助服务机）这种对资源敏感的客户端，即使是 n^2 和 n*logn 都会体现出明显差距。

反编译后的字节码很清晰了：编译优化成查表后把枚举类进行了标量替换，tableswitch 里的数字应该是直接放在方法栈里，避免了去堆里访问对象，所以快了很多。

线程卡死本身和 stream 没啥关系。
但这个代码写的实在是太辣了。stream 不是让这么用的。

当你在 3 张表以上的 join 加一堆 where...on 时，已经是在 SQL 里写业务了。
联查最大的问题是制约了数据库设计，一般认为 mysql 单表几千万是上限，超过该规模考虑分表。联查的索引不易设计，很容易在业务规模还未扩大时就整出慢 SQL 。
所以三大范式在实际业务中很少遵守，往往是弱耦合 + 宽表的设计思路。数据规模再扩大就上列式存储，不会尝试在关系型数据库死磕。

当然一切都不是绝对的，如果你的 User 表几千条，Department 几十条，Organization 几十条，想怎么 join 都行。但还是建议在代码层解决问题，除非涉及到性能问题。

不要在 sql 里写业务逻辑。

如果你的执行函数可以不区分前后，那还叫流式处理吗？
真实场景到底是什么？建议讲清楚。