@whoami9426 very good

我一直有个想法没空去实现，对这种使用 copyProperties 方法的两个对象，解析其 class
1.比对两个 class 的字段，然后将差异列出来，比如 target 有但是 source 没有的字段，还有同名字段但是类型不一样的字段（此类情况最好直接能调用 idea 的告警将类型不一样的字段告警出来）；
2.在点击 target 的 setxxx 方法时能把使用 copyProperties 方法的地方作为其引用。
楼主要是能把这两个功能实现一下这个插件的价值会更大些。

没啥区别，不想用 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