没啥区别，不想用 Mybatis Plus 想用原生 Mybatis 就可以使用 PageHelper ，不然就直接用 Mybatis Plus 自带的分页好了，不过 Mybatis Plus 确实比较糙，我也贡献过对 limit 的一个优先

杭州 java 2.5w 6 年

用来凑数的，我自己在公司也提交过，主要是给公司免税还有申请什么资质之类的使用，过了还有钱拿。

我去年从网易云切换到 notion 了，体验真的爽飞。

可观测性比较适用于大型成熟系统，小项目基础设施搞得再好如果只有零星几个开发那也没多少收益。可观测性目前主要分为几大块，log （日志）、trace(链路）、metrics （监控）、alarm （告警），对于小项目来说要有取舍，比如题中提到的 skywalking 我司目前也是用的这个并做了二开但是这是建立在核心系统有超过 60 个应用，上千个 pod 的基础之上的，小项目哪怕使用微服务应用数也很有限，链路本身就不复杂，所以链路的优先级远远低于日志（日志中有 tid 其实可以脑补串联起链路），剩下的监控和告警常常是一起的，Prometheus 几乎是事实意义上的标准了，只有告警成本较高收益不明显，资源告警和业务告警搞起来不要太复杂。所以小项目资源紧张的情况下优先保障日志（日志规范其实也很有讲究有很多技术手段可以做），其次有空余资源就把监控（ jvm 内存、进程内存、gc 、cpu 、磁盘 io 、网络 io ）搞起来，链路和告警可以在项目有更大的发展之后再逐步引入。

结论是没有。
好处之一有点类似我们自己工程中的多 module 结构一样，看源码的时候可以更清晰，引入依赖可以按需引入而不是全量引入，很多框架以前为了这个事情自己把使用的类从 jdk 里面 copy 出来（ copy 一个类往往还没用还要 copy 依赖的类想想心累不），有了模块化以后就不用再干这种脏活了，当然上面的事情和 web 业务开发基本没啥关系，主要是框架和中间件影响比较大，但其实这一举措主要是 java 还不想放弃桌面端，java 做桌面端以前最被人诟病的就是要带着 jre 一起发布整个包大到离谱，有了模块化用户就可以自己裁剪出需要的 jre 能显著地降低包的体积有利于分发；
第二点就是精细化权限，我可太喜欢这个东西了，甚至一度想把我司的屎山从 jdk8 迁移到 17 ，虽然最后没有成型，比较典型的一个场景是框架中 A module 的类只想给自己框架内部的其它 module 使用，但是很难做到这一点，设为 default 则要求其它模块使用它的类的包名与其一致，设为 public 则存在被业务滥用的风险，现在总归存在一种机制能解决这个事情了。

不需要，不用看其它人说的直接看官方 https://openjdk.org/jeps/444
Do not pool virtual threads

有对应的 idea 插件吗，当字段类型不一致时做提示（可配置为严格模式，严格模式直接报编译错误），还有两个实体的字段差异最好也能在悬浮窗上展现出来，感觉现有的 bean copy 在这方面都不咋的。

想法挺好，就是已经有这样的轮子了
<dependency>
<groupId>com.taobao.arthas</groupId>
<artifactId>arthas-vmtool</artifactId>
<version>3.7.2</version>
</dependency> 而且 arthas 已经经过大规模使用验证了

小应用随便玩，大的这么玩，基于 http 接口的文档生成工具比如 swagger 就废了，你要自己手写接口文档还要维护，静态代码分析系统也没啥用了，一个应用就一个接口要干啥肯定不知道，全链路系统好一点，但也只能用 tid 去查，其它维度的查询都废了，监控告警系统基于接口的统计比如调用量、平均 rt 、95 线、97 线、99 线也都无了，简而言之可观测性被你全废了。

这问题想问的是推送，如何把某个用户的信息反向推送到浏览器，浏览器到用户有 nginx 代理 tcp 直接就能找到，这问题说大不大说小不小，简单来说就是维护 user 和 server 的关系，但如果 server 的量级超过 100 就会复杂的多，多活容灾每个细节都值得大费篇章。

@Aresxue 其实可以把虚拟线程学起来了，有了这玩意之后绝大多数场景就不再需要线程池了，线程不会再成为应用的瓶颈，目前 jdk21 中的功能已经勉强可用，预计下个 LTS 版本能基本稳定下来。

@baolinliu442k 并发度和 cpu 核数有关系但没太大关系，cpu 哪怕是单核因为时间片是轮转的从使用者视角来看任务都是并行的，回到你这个问题从普通的使用者视角可以认为同时执行 10 个任务，但如果是按真实的占用 cpu 去执行逻辑这个角度，哪怕你有 5 个核，这 5 个核同时被你的任务使用的时间几乎是没有的，因为还有 tomcat 线程、rpc 线程池等其它活跃的线程共享你的 5 个核。

1.视业务而定，如果是一个低频的业务和其它业务共享一个线程池也无伤大雅，如果相对并发较高，最好是指定用自己的线程池而不是公用的线程池，@Async 也是可以指定线程池的，和 private static 的方式基本上是等价的，大多数情况下都可以用它；
2.参数没有标准，完完全全根据业务的情况而定，这个情况不仅是当下还有对未来的适当评估；
3.线程池主要是用于隔离线程资源和多参数任务并行降低 rt ，其对于整个应用资源的利用率并不会有显著的提升；
4. execute 适用于没有返回值的任务，submit 的返回值是 Future ，基本上能用 submit 没啥必要了，CompleteableFuture 本来就是为了加强 Future 的。

对于业务中我是建议能不能则不用，作为排名靠后的一个选择，顺便贴一些使用线程池的注意点：
- 合适的任务队列及其大小，过大会造成 oom ；
- ThreadLocal(登录信息上下文或其它的业务信息)丢失；
- 全链路 id 丢失；
- 合适的线程池策略和线程数(固定数目和不定数目)；
- 任务重启丢失(优雅退出)；

应该不是服务端问题 ，用 arthas trace 一下看看，实际中 es 的连接数、反序列化都会影响最终的性能。

值得的：Netty
架构设计的好看的：Dubbo
理念完善的：Spring
实现巧妙的：AQS 、ConcurrentHashMap
贴近业务的：Rocketmq

@RichardX2023 核心原因是 java.sql.Connection 不是线程安全的，所以每个线程只能独占一个链接，对于你说的 20 个任务 10 个 work 线程的情况可以对线程池加以改造，提交任务（必须是批量提交）的时候根据剩余可用连接分配一定数目的链接（这个算法决定了这个策略的健壮性），比如 20 个任务可以分配 5 个链接，然后每 4 个任务共享一个链接，当然这四个之间就要排队了对耗时的优化肯定没有一个任务一个线程效果这么好，但并发度确实也从 1 变成了 5 。

软件工程没有银弹。
synchronized 是可以在后续被 JVM 优化掉的，而且实在不行替换成 ReentrantLock 的操作也还是比较简单的。ThreadLocal 才麻烦，不过 scoped value 成熟后应该也可以搞的定。
就是现阶段替换虚拟线程的成本和收益不明显而已，但如果是一个长远规划的项目早做早好，小项目玩玩也可以。