对象通常先分配在新生代，短命对象会被快速回收，存活久的对象会晋升到老年代。真正有用的理解方式，不是背一堆名词，而是抓住一条主线：对象怎么创建，怎么分配，怎么存活，怎么晋升，最后又怎么被回收。大多数对象都很短命，所以 JVM 才会采用分代思想，把“容易死的”和“活得久的”分开处理。很多时候，真正有效的优化不是一上来改 JVM 参数，而是减少对象创建、缩短对象生命周期、避免大集合无限增长、降低一次请求

它能减少频繁创建线程的开销，但如果线程数、队列和拒绝策略设计不合理，也会带来堆积、延迟和资源耗尽的问题。线程池配错了会堆积，锁用错了会死锁，队列无限大了会把内存吃光，任务一多还可能把下游直接打挂。真正成熟的并发理解，是能提前想到任务会不会堆、线程会不会爆、锁会不会争、数据会不会乱。如果没有线程池，每来一个任务都创建一个线程，成本会很高。线程池、锁、队列、拒绝策略，这些看似基础的东西，实际上决定了你

你把 IOC 和 AOP 说清楚，Spring 的后续内容，比如事务、代理、Bean 生命周期，也就顺着通了。Spring 之所以能成为 Java 后端最常见的开发底座，不是因为它名气大，而是因为它把两件非常麻烦的事情做顺了：对象怎么管理，公共逻辑怎么复用。如果你面试时能顺着这条线讲，就会显得很自然：先扫描 Bean 定义，再创建对象，然后完成依赖注入，最后初始化并交给容器托管。一个是对象层面的管

所以它之所以像“默认接口”，不是因为大家突然统一审美了，而是因为它把 Agent 工程里最麻烦的那件事标准化了。如果你在做一个 Agent 系统，MCP 不是“要不要用”的问题，而是“什么时候开始需要标准化”的问题。也就是说，Agent 真正干活时，不是在“纯聊天”，而是在一边想，一边调工具。真正要命的是，工具会不断增加，需求会不断变化，系统还得保持可维护。工具失败了，Agent 是重试、降级，还

官方文档里已经把它描述成会自动索引仓库、生成架构图、源码链接和代码总结，还能通过 MCP 直接读 wiki 结构和内容。问浅一点的问题还行，问深一点、跨文档、跨时间的问题，模型就容易重复劳动，甚至前后不一致。如果问题很复杂，比如要横跨十几篇文档、好几轮任务、多个矛盾来源，模型每次都重新检索和重组，成本就高，稳定性也一般。由 LLM 维护的一组 markdown 页面，负责摘要、实体页、主题页、关联

Tool Calling 不触发，很多时候并不是“模型太笨”，而是工程链路里某一层没有对齐。我的经验是，先查注册、再查描述、再查 Prompt、最后查模型和网关，通常都能比较快定位到问题。如果后面要继续做 Spring AI 落地，我会更建议把这套排查顺序固化成清单，因为它真的比临场猜原因省时间得多。

你到底该用STDIOSSE还是？你的 starter 该是普通版还是webflux版？type该是SYNC还是ASYNC？MCP tools 发现后，是否真的进入了？聊天链路有没有真正拿到这些？多 MCP server 场景下，工具名是否冲突或被自动改写？自动初始化是不是把问题提前到了启动阶段？你现在验证的是“能连”，还是“模型真的能用”？

QPS 上不去，数据库当然值得查，但不应该只查数据库。线程池、连接池、外部依赖、日志开销、压测模型，这些都可能成为真正瓶颈。我越来越觉得，性能排查里最怕的不是系统慢，而是还没把瓶颈范围看完整就急着下结论。

Spring AI 结果不稳定，很多时候不是框架问题，而是约束条件还不够稳定。Prompt、模型参数、工具描述这三层只要有一层比较松，最终表现就容易波动。工程场景里，想要稳定结果，靠的不是“多试几次”，而是把可控因素一点点收紧。

Spring AI 结果不稳定，很多时候不是框架问题，而是约束条件还不够稳定。Prompt、模型参数、工具描述这三层只要有一层比较松，最终表现就容易波动。工程场景里，想要稳定结果，靠的不是“多试几次”，而是把可控因素一点点收紧。