应该是用 java.lang.instrument.Instrumentation 或者 Java TI, 前者的可能性更大一点, Idea 热更新好像不能修改类成员信息, 不然会更新失败

稍微有点卡, 但是总的还是变顺畅了一些

@drymonfidelia 8 * 500W 就是 4000 万了- -, 你可以试着把 join 的表去掉, 看看单表查询效率

@salmon5 Tomcat 很多其实是 IO 密集型请求, 为了降低响应时间, 这么做可以理解, 因为客户端还等着呢, 每个场景有自己测重点; JUC 牺牲一点实时性, 减少系统资源消耗, 在异步执行实时性要求不高的任务, 这个设计挺好的

假设的有十个并发任务需要处理, 每个任务需要 10ms, 当前核心线程池是 5, 用队列的理想时间是 20ms, 不需要创建销毁线程, 如果立马增加 5 个线程, 处理的理想时间大概是 10ms, 空闲后需要销毁, 如果类似的场景很多, 就需要频繁的创建销毁, 用队列可以做到削峰平谷, 避免以上场景造成的线程创建销毁的开销

我觉得是因为任务应该很快就可以被处理, 在队列里留存的时间很短, 所以可以先不创建新的线程, 直到队列满了表现出线程池的计算能力真的不够用了, 再启动线程去消费队列, Doug Lea 觉得这样处理适用于大部分场景吧

你说的索引失效是指 C 表全表扫描了吗

问题 1: 你的表有些索引的基数太低了, 效率不高, 比如 CodeStatusId, packageId, 看 cardinality 这个字段, 数字越大数据越分散越好, 如果基数太小, MySQL 可能会觉得不用索引效率更高, 建议合并或者删除一些索引; 问题 2: 都是 inner join 会产生, ,每次都要创建临时表, 做文件排序, 可以尝试通过子查询或者其他方式写. MySQL 本身提供 optimizer_trace 功能, 但是需要开启, 可以看到 MySQL 分析结果,不过 RDS 怎么搞还没弄过

这也能上钩

3.你认为解决高并发问题的本质是什么？
我认为是解决客户端体验一致性问题, 因为客户端不能理解为什么并发高低会影响服务, 对于客户端来说, 它希望服务端的表现不要偏离这个预期, 偏离这个预期就算破坏了客户端体验的一致性;

@qloog 差点颠覆我 RabbitMQ 三观

可能因为引入了行内自动补全导致资源消耗变大了

不论隔离级别是啥都不允许脏写, update 是当前读, 你的条件会加间隙锁,其他的事务会阻塞,直到事务提交,或者超时

@yol947 这也没有渠道买- -

@Overbye 谢谢兄弟

去柬埔寨搞开发? 你不是好人, 心术不正, 吃点亏是难免的

@invalid522 想换个 iphone, 即支持当前的 nano sim 阶段, 又能满足未来 esim, 如果不能满足这个, 只能再等一段时间了

港版 iphone15 支持 esim 吗

为什么程序员做产品要出海, 这个问题拆成为什么做产品要出海和为什么不优先选择国内市场