@passerbytiny #48 爱抬你就多抬点,我当乐子看

@ryd994 #33 都说了大数据量,概率再低不是没有概率
我明确说明是大数据量就是防止你这种说概率低的抬杠,没想到你还是来了

优势:无规律,碰撞小
劣势:无规律,大数据量一样会碰撞
总结:建议使用雪花算法等解决碰撞问题

黑名单+1

1.索引字段不使用函数
2.sql 的 group by 优于内存处理的 list.stream.Collectors.groupingby
3.联表查首选于单表查
4.数据量大时，考虑分表

1 没问题
2 看情况,比如是需要原始数据+分组后数据的用 stream 肯定好因为用 sql 的 groupBy 要查询两次
3 煞笔
4 没问题

所以你领导 100 分能得 67.5 分,及格而已

日常傻逼架构欣赏 1/1

bio nio 多路复用(select poll epoll) aio 按这个顺序看

@no1xsyzy #23 比较长的链式嵌套确实存在阅读的困难,但是他这个链式写得一点都不多也不长还远远称不上"阅读困难"或者"语意不清"
比如使用 Stream.of(1,2,3).map().filter().flatMap()..... 这种大段的链式调用也有解决方案 在每一个调用后换行写注释即可
函数式编程核心就是纯粹的链式调用,其次是 builder,然而二者都是存在链式调用 所以链式调用没有任何问题
你把链式调用去了换成其他代码一样存在阅读困难,本质上不是代码怎么写,而是写代码的人的问题

@Heylion #21 SimpleDateFormat 存在并发问题不建议使用甚至禁用,没有说他的代码会有问题
如果一个方法存在问题,那么在有代替品的情况下应当使用代替品
时间的格式化 java8 有 LocalDateTime java8 之前可以用 apache-dateUtils dateFormatUtils
所以 SimpleDateFormat 这种存在问题的类有必要使用?

@wsy190 #16 非大佬,只是觉得你纠结的东西微不足道
写代码多写注释,代码千变万化注释一行足以
如果给你一个十万行代码的类,但是注释就一句 输入 1 返回 1 你觉得哪个更好?
代码只要不出错没并发就是好代码,写法因人而异
记住有一万个哈姆雷特,你只是其中一个罢了

@Aresxue #9 构造器存在强制依赖问题,如果发现无法注入整个项目都无法启动也无法在运行是修改注入的 bean,当多个构造器(5 个以上)时代码会变得很难看
构造器虽好,但是不建议使用

还有 SimpleDateFormat 高并发下存在问题,都已经禁用的东西你还敢用
你多久没有学过新技术?

链式调用,没任何问题啊
链式调用一样可以写注释
而且第二段代码和第一段完全不一样,第一段只是单纯的 set 第二段有大量的判断逻辑能一样比较?
链式调用也是炫技?我活在 2000?

1 是正确的 2,3 是什么鬼
现在一般都转成 json &n=[1,2,3]这种形式传输

访问一次 redis+1,达到限定次数后返回限制异常信息
解析问题,别把简单问题复杂化

蜜罐开源怕是分分钟被破

没有你的烦恼