软件技术实习总结〔2026范文〕
两个月实习，干了两件能拿出来说的事：修了一个内存泄漏，把一个慢接口从两秒多压到两百毫秒以内。不吹不黑，这里头没多少高深理论，全是踩坑和填坑。
先交代内存泄漏那次。第二周压测，第二天早上看监控，服务响应时间从50ms飙到800ms，Full GC两分钟一次。当时心跳都漏了一拍——刚接手代码就出这事。我做的第一件事不是改代码，是保现场：把heap dump拉下来，用MAT打开。一看，OrderContext对象占了堆内存的60%，数量12万个，正常应该只有4千左右。谁在留它？顺着引用链追，发现每次订单路由都会new一个RouteEngine，里面强引用OrderContext。业务异常分支里，这个RouteEngine没被销毁，而且它还注册到了一个全局事件总线上，异常退出时忘了注销监听器。
改法分两步。第一步，给RouteEngine实现AutoCloseable，在finally里调用close，清理上下文。第二步，事件总线的监听器注册改成WeakReference。这里有个坑：第一次改完，发现有些监听器被GC过早回收，业务事件收不到。后来用Guava的WeakKeyHashMap兜了一层，保证监听器还在用就不会被回收。改完后压测八小时，OrderContext对象数稳定在4500上下，Full GC频率降到半小时一次。说实话，之前只在书上看过内存泄漏的案例，亲手走一遍引用链，才明白什么叫“GC root可达”。
再说订单列表接口。数据量上来就超时，代码里已经加了索引，没卵用。我抓了慢查询日志，原SQL长这样：order_list left join user_info left join product_detail，三个表，回表次数230万。执行计划里rows_examined吓死人。我干了件事：跑去问产品，列表页到底要展示什么？产品说订单号、状态、下单时间就够了，点进去才看详情。那不就结了？不需要联查用户昵称和商品图片。
重构逻辑：主表只查订单核心字段，用户昵称和商品图片改用懒加载，前端滚动到可视区域时单独发请求。订单状态枚举的映射从数据库字典表挪到本地缓存，用LoadingCache，refreshAfterWrite设了30秒，过期后只有一个线程去加载，其他线程返回旧值。改完再看执行计划，rows_examined降到2.1万，接口TP99从2.3秒掉到180毫秒。P95更漂亮，只有95毫秒。最慢的一次300毫秒，那是因为用户订单量特别大，分页扫了深翻页——这块后来加了游标分页才彻底解决。
这两件事让我对“完成”两个字有了新理解。以前功能跑通就算完，现在至少得问自己三个问题：异常分支有没有资源泄漏？并发下有没有竞态？数据量翻十倍会不会崩？举个例子，写文件导出，以前FileOutputStream套个BufferedWriter就完事，现在会考虑用try-with-resources，考虑分页查询内存占用，考虑用户中途取消怎么中断线程。
还有团队代码规范，以前觉得是摆设。经过这两次故障排查，发现每一条背后都有血泪。比如“禁止在循环中调用远程服务”，听起来像废话，可真有同事在循环里调用户中心接口查昵称，100条订单就是100次RPC。代码审查时我抓到过一次，没直接怼，而是把压测数据贴出来：加了这100次RPC，接口响应时间从200ms涨到4秒。对方看完自己就改了。
当然也有翻车的地方。内存泄漏那次，其实监控告警提前三天就出现了——老年代占用曲线一直在爬坡。但我当时对Prometheus面板不熟，没看懂那个斜率。后来专门花了一天时间，把每个指标的含义过了一遍，又写了个小脚本每天凌晨自动拉堆内存快照，比对对象数量的变化趋势。脚本很简单，就是jmap加个定时任务，但有了它，下次再有泄漏苗头，半小时内就能发现。
回头想想，这次实习最大的收获不是技术本身，而是一种“故障转化”的能力。说白了，线上出一次问题，如果你只是重启了事，那就是纯损失；如果你能定位根因、修好、写进checklist、甚至做成自动化检测，那这次故障就成了团队的资产。我把自己处理过的两个问题整理成文档，丢到团队知识库，还在周会上做了一次十分钟的分享。后来看别人的代码审查意见里，开始出现“注意事件总线监听器注销”这种话，我就知道，这坑没白踩。
下一步打算继续啃两个硬骨头：一是JVM参数调优，目前用团队现成的模板，想自己动手调CMS和G1的几个参数，在测试环境跑对比；二是分布式链路追踪，实习期间只用过SkyWalking的界面看调用链，没插过自定义埋点，这块得找个业务场景练练手。
代码写得再漂亮，扛不住真实流量也是白搭。以后再看别人的代码，我会先问一句：这儿要是挂了，你能兜住吗？
- 零思考方案网小编为您推荐工作总结专题，欢迎访问：工作总结
