V2EX › LiaoMatt 的所有回复 › 第 4 页 / 共 6 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6

❮

❯

2024-05-15 14:17:00 +08:00

回复了 HAPPYISOKA 创建的主题 › Java › V 友们有没有 springboot 整合 netty 的脚手架

长连接只做登录认证好浪费

2024-05-15 12:27:08 +08:00

回复了 HAPPYISOKA 创建的主题 › Java › V 友们有没有 springboot 整合 netty 的脚手架

@HAPPYISOKA 这个我熟, 你们交互用啥, JSON? protobuf 还是其他

2024-05-15 09:10:42 +08:00

回复了 liv22 创建的主题 › 长沙 › 120w 是买长沙还是广州？

按照现在的行情, 买到就是亏到, 我个人会相信高盛的房地产分析, 国内房价还有下探空间; 既然你都怕 35 被裁员, 那就更不应该强行买房了, 总之先不急, 也别炒股了, 现金为王, 个人观点仅供参考

2024-05-14 15:51:00 +08:00

回复了 hades97 创建的主题 › 程序员 › 召唤猛男，我写的钓鱼 web 工具《路亚记》，大框架已经写好了，希望能有人一起开发

很有意思

2024-05-13 18:06:50 +08:00

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

@shockingFly 确实

2024-05-13 16:29:16 +08:00

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

@huangcjmail 底层只要是 B+树就可以这么分析, 思想是趋同的

2024-05-13 14:33:38 +08:00

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

@FlyingBackscratc 应该就是 sid_date_time 联合索引 sid 基数太少导致, 你使用 >=是无法利用组合索引的, sid 的基数太少, 需要扫描的页过多, 而且你是取所有数据, 还需要回表, 数据库引擎觉得全表扫描的成本比通过 sid + 索引下推 + 回表的成本低, 所以选择全表扫描

2024-05-13 14:15:44 +08:00

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

可能是 sid 作为索引基数太小了, 数据不够分散导致? 可以看下 optimize trace 分析

2024-05-12 22:07:57 +08:00

回复了 857681664 创建的主题 › 程序员 › 抱着想写好质量代码的心，然后遇到一个完全不管代码质量的人合作，真是糟心

你们公司还招人不, 让我来吧, 这老哥的操作听起来就很迷, 很有必要做一下 codereview

2024-05-09 17:44:53 +08:00

回复了 studyrun 创建的主题 › 程序员 › 一些正向作用的后门接口有没有其它的名称，直接叫后门不太好听

数据补偿
recover

2024-04-30 09:19:35 +08:00

回复了 waterlaw 创建的主题 › 程序员 › idea 跑项目 build 一下修改的 Java 代码是如何生效的？

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

2024-04-28 15:16:57 +08:00

回复了 Playmaker86 创建的主题 › 程序员 › jetbrains 全家桶升级 2024 后，在滚动代码时候感觉有点掉帧

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

2024-04-28 14:08:09 +08:00

回复了 drymonfidelia 创建的主题 › 数据库 › 求助一个排查了半年没解决的 MySQL order by 子句导致索引失效的问题， 500 多万条记录的小表要查快两分钟

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

2024-04-28 11:24:37 +08:00

回复了 lsk569937453 创建的主题 › Java › [ Java ]中的线程池工作原理，为什么不是先创建线程而是先往阻塞队列里塞任务？

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

2024-04-28 11:06:23 +08:00

回复了 lsk569937453 创建的主题 › Java › [ Java ]中的线程池工作原理，为什么不是先创建线程而是先往阻塞队列里塞任务？

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

2024-04-28 10:51:59 +08:00

回复了 lsk569937453 创建的主题 › Java › [ Java ]中的线程池工作原理，为什么不是先创建线程而是先往阻塞队列里塞任务？

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

2024-04-28 09:34:19 +08:00

回复了 drymonfidelia 创建的主题 › 数据库 › 求助一个排查了半年没解决的 MySQL order by 子句导致索引失效的问题， 500 多万条记录的小表要查快两分钟

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

2024-04-28 09:21:27 +08:00

回复了 drymonfidelia 创建的主题 › 数据库 › 求助一个排查了半年没解决的 MySQL order by 子句导致索引失效的问题， 500 多万条记录的小表要查快两分钟

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

2024-04-25 18:06:17 +08:00

回复了 cnhongwei 创建的主题 › 互联网 › 下载了一下假的 bandizip，这种网站和软件就没有办法了吗。

这也能上钩

2024-04-25 12:08:21 +08:00

回复了 dumbbell5kg 创建的主题 › 数据库 › 昨天面试的几个 MySQL 和 Redis 的题目，来请教一下

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

1 2 3 4 5 6

❮

❯