1. 自我介绍

面试官您好，我叫周子斌，目前就读于郑州轻工业大学软件工程专业，主要方向是 Java 后端开发和 AI 应用开发。
技术方面，我熟悉 Spring Boot、Spring Cloud Alibaba、MySQL、Redis、RocketMQ、Dubbo、ShardingSphere 等常用后端技术栈，也有 Spring AI Alibaba、RAG、MCP、RAGAS 等 AI 工程化实践经验。
项目方面，我做过 SaaS 短链接系统，主要解决了高并发跳转、缓存穿透、缓存击穿、分库分表和异步监控数据落库等问题；也做过面向电商场景的 AI 导购助手，结合问题重写、意图识别、多路召回和 RAGAS 评测来优化问答效果。
我也参与过 Apache Dubbo 和 Spring AI Alibaba 的开源贡献，比如修复过 Dubbo Mesh 路由中 IPv4 地址匹配异常的问题，也参与修复过 Spring AI Alibaba 中会话记忆淘汰逻辑的问题。这些都是我在研究项目源码的时候发现的问题，然后在github上提issue，再去PR修复相关问题，并且都merge到了matser分支里。
目前我希望找一段java/ai应用后端开发的实习工作。

2. 奖项说明

我们当时的项目叫”植”播间，是我和我实验室的同学共同参与的。主要面向农业大棚里作物状态的监控。
通过yolo图像识别去识别作物状态，然后将作物状态同步到移动端。
我主要就是负责移动端微信小程序的编写，负责软件全栈开发。
后端使用 springboot 框架去写数据的存入，将数据存到微信的云服务器上。
而前端UI部分我则是接触了 AI 工具，当时使用cursor 和 claude 3.5 sonnet 去完成了UI编写。

这个 bug 是我在看 dubbo mesh路由模块 的源码发现的。
路由的 IP匹配方法 使用了 NetUtils 包里的一个二参方法。
但是我发现这个方法有 bug ：
普通的 host/port 地址处理拆分出现了问题，具体就是冒号判断放在了后边。导致没办法解析正常IPv4
我一开始是直接重构了这个二参方法，并提交了PR。
但是dubbo的maintainer review的时候给我的 pr 留评论说建议不要再扩大这个旧方法的语义。
于是我将mesh路由里的IP匹配调用了一个原有的三参方法，将原本的 NetUtils 里的方法加上了废弃注解。
最后这个PR通过了 review 和 CI ，merge到了dubbo的master分支。
前段时间我在研究 Dubbo Mesh 路由的时候，发现 MeshRuleRouter 在处理多个 match 条件时用了 allMatch。我结合 Istio VirtualService 的语义分析后，认为这里应该是 anyMatch。为了验证不是自己的理解有误，我专门写了一个回归测试，确认多个互斥条件无法命中，然后查阅了 Dubbo 官方 Mesh 文档和 Istio 官方文档，最终向 Apache Dubbo 提交了 Issue，目前也准备提交修复 PR。

我的这个比特严选的项目用到了这个框架，使用了admin模块里的会话记忆add的方法。
这个add的淘汰策略是判断会话大小是否大于配置上线，如果大于，弹出最初的会话。
但是这个方法里直接使用了message.size()去和maxmessage进行了判断，而不是redis缓存里的会话大小。
导致小批量追加消息的话最初的消息不能弹出导致会话大小越来越大。
我当时配置缓存上限是20 但是发现redis缓存里会话的消息数超过了20
然后就发现了这个bug 去github上提交了issue
具体就是将当前传入消息次数改成了redis里历史会话消息，避免了历史消息不断膨胀。
PR 通过了 review 和 CI ， merge到了 spring ai alibaa的 master 分支。