昨天早上到工位先拉了最新代码git pull完直接炸了三个文件冲突有个同事昨天重构了公共模块我这边分支还停在上周的版本上手动解了二十分钟冲突解完跑测试发现还有个地方逻辑对不上又去找他确认了一遍。上午一直在调一个分页查询的接口数据量大概80w之前用的limit offset分页翻到后面几页越来越慢接口响应直接飙到3s。查了下执行计划offset太大的时候mysql要扫描大量无用行然后丢弃经典的深分页问题。改成了游标分页用上一页最后一条记录的id作为条件where id lastId order by id asc limit 20这样走主键索引不管翻到第几页都是毫秒级。但是产品那边不接受说用户需要跳页游标分页没法跳页。最后折中方案前100页用offset超过100页提示请使用搜索条件缩小范围。虽然觉得这个方案很丑但也没更好的办法了总不能为了一个没人会翻到第200页的功能去上ES吧。下午帮新人看了个bug他写的接口偶尔会报空指针自己查了一下午没查出来。我一看多线程环境下往一个HashMap里写数据并发put的时候内部resize导致数据丢失经典问题。让他换成ConcurrentHashMap就完事了这种坑其实新人很容易踩学校里学java的时候基本不会讲这些。快下班的时候收到告警线上某个服务内存占用突然飙到85%看了下监控下午三点左右有一波流量突增GC频率明显变高了。初步怀疑是某个查询没加缓存大量请求打到db的同时对象创建太多年轻代不够用频繁触发minor gc。先加了个redis缓存顶着明天再细查。今天又是被各种破事填满的一天真正写代码的时间大概也就三四个小时剩下的全在解冲突、看日志、帮人排查问题。不过那个深分页的问题倒是挺有意思的之前一直知道有这个坑但实际项目里第一次认真处理记录一下下次遇到类似的直接套方案。