@wysnylc 这个 api 的入参不是队列容量吧

@sagaxu 一般的条件 IDEA 插件自动生成 只有很特殊的才要写

根据自己分发的 clientId 来区分,在 api 网关转发

用这个都要加个 exceptionally(tx -> {log...})
不然你找不出问题

@lichengzhang2005 我想楼主吐槽的不是大小的问题, 一个项目引用各种重复功能的依赖 配置方式不统一

@xiangyuecn TimeUnit.DAYS.toMillis(days) Duration.ofDays(1L).toMillis()
就行了 善用工具类

变量上的注释应该要说明是干嘛用的 而不是 // 声明变量

@passerbytiny 哪里坑?

@yanshenxian 我觉得这 2 种都行,还是看看实现的具体方式 任务堆积的话会有警报给运维
现在的业务规模大部分情况都不会堆积, 主要是为 11.11 做准备

@yanshenxian 业务场景不一样 现在的任务顶多几百个 但是每个时长都不确定 有的很长有的很短 处理长的不能妨碍短的

@abcbuzhiming 为啥我这里测试和你相反..jdk11 更快
而且之前测试过 jdk11 的 stream 耗时更加平均 jdk8 的第一次跑就很慢

@autoname 说明你连的不是中央仓库,或者其他的一些网络原因

@vigidroid +1 不过这个缺点是任务多了启动好慢 不知有什么方法可以解决

配置下 Serializer 和 Deserializer 就行 Jackson jsr310 的包都有
redisson 依赖的 FstCodec 默认就支持

线程池初始化 bean 默认是单例所以这个一般没什么问题 不过也不太优雅

但是他把服务器的请求线程又汇聚在线程池的队列里 又在里面 get() 其实是更慢了

@BlackBerry999 如果是 4900hs 我是真的心动了

@Sasasu 这个问题有考虑过 不过是商品信息

@LMuyi 4 楼那个是对的就是符合你的这个需求 unless 里的表达式为 true 不缓存结果

@czhu 拿来缓存用我估计就是速度会快一些和减少访问硬盘次数来增加硬盘寿命