从第二期开始说这次聊聊 SpringBoot 项目里真正绕不开的东西上一篇把 SpringBoot 的项目骨架、分层结构和基础注解讲完之后不少朋友在后台留言说最想看的还是“项目里真正踩过的坑”和“面试时被问到的点”。这一篇我就顺着这个思路把配置体系、Flowable 流程引擎集成、自动装配原理、监控调优这四块展开讲。内容都是我在实际 SpringBoot 项目里反复碰过、排查过、优化过的东西不是背书式的官方文档复述。这套内容适合谁适合已经能跑起一个 SpringBoot Demo、但一进真实项目就发懵的同学也适合准备跳槽、需要把 SpringBoot 项目经验讲出深度的开发。全文没有太多废话每一节都能直接对应到项目开发和面试场景。1. 从项目视角重新理解 SpringBoot 配置体系1.1 配置优先级与常见坑SpringBoot 的配置优先级是面试里特别爱考、项目里特别容易出问题的点。官方文档给了一大堆顺序但实际开发中你只要记住这条核心链命令行参数 Java 系统属性 操作系统环境变量 application-{profile}.yml application.yml SpringApplication.setDefaultProperties我见过很多次“配置不生效”的排查过程最后发现是启动脚本里加了--server.port8081而配置文件里写的是server.port8080结果怎么改 yml 都没用。这是典型的命令行参数优先级最高导致的。另一个容易踩的坑是 profile 文件的加载逻辑。application-dev.yml不会自动生效必须在application.yml里配置spring.profiles.activedev或者通过启动参数--spring.profiles.activedev指定。如果你的环境没有显式激活 profileSpringBoot 只会加载默认的application.yml所有 profile 相关的配置全部不生效。还有一个注意点同一份配置里spring.config.additional-location和spring.config.location这两个参数很容易混淆。前者是追加外部配置目录后者是替换默认配置位置。生产环境一般只用前者因为后者会把 jar 包内置的配置文件整个干掉稍不注意就连数据源都起不来。1.2 自定义配置绑定ConfigurationProperties 比 Value 好用在哪很多项目里还在大量使用Value(${xxx.yyy})注入配置这个写法本身没毛病但当你有一组关联配置时就会变得非常痛苦。比如配置一个短信渠道商的信息sms: provider: aliyun access-key-id: xxx access-key-secret: xxx sign-name: 测试签名 template-code: SMS_123456用Value的话你得写四个字段每个都要写注解而且字段类型不会自动做复杂转换。用ConfigurationProperties就清爽很多Component ConfigurationProperties(prefix sms) public class SmsProperties { private String provider; private String accessKeyId; private String accessKeySecret; private String signName; private String templateCode; // getter/setter 省略 }这里有个关键点access-key-id这种 kebab-case 写法会自动映射到accessKeyId字段这是 SpringBoot 的宽松绑定规则。但如果你用Value就必须严格写Value(${sms.access-key-id})字段名和配置文件里的写法完全一致才行宽松规则不生效。还有一个进阶用法是把配置绑定做到不可变对象上用ConstructorBindingConfigurationProperties(prefix sms) public class SmsProperties { private final String provider; private final String accessKeyId; // 构造方法省略 }这样配置类就是只读的从设计角度更安全也符合依赖注入的思路。我去年把一个老项目的Value全部迁到ConfigurationProperties之后配置类清晰了很多单元测试也好写多了。1.3 多环境配置怎么落地现实项目里至少有三套环境开发、测试、生产。如果一个 yml 文件里塞满了各种环境的地址切换部署的时候改来改去迟早出事。推荐的做法是拆文件application.yml application-dev.yml application-test.yml application-prod.ymlapplication.yml里只放公共配置比如应用名、编码、日志级别兜底。环境相关的内容全部放到对应 profile 文件里。然后通过启动参数指定环境比如测试环境启动命令java -jar demo.jar --spring.profiles.activetest这里我特别想提醒一个容易漏的配置环境标识要尽量早地暴露出来。我习惯在application.yml里加上一个自定义配置app: env: profile.active结合 Maven 的 profile 做资源过滤构建时就确定环境标识。这样在日志里能直接看到当前是什么环境避免“明明部署的是生产包结果连的是测试库”这种低级事故。多环境配置的另一个坑是数据库密码。很多团队把明文密码写在application-prod.yml里提交到 Git这是很大的安全隐患。至少要用环境变量占位符spring: datasource: password: ${DB_PASSWORD}这样代码仓库里不会有真实生产密码部署时由运维在服务器环境变量里注入。如果你的团队有条件可以接配置中心但也不要因为有了配置中心就把所有配置都扔进去应用自身的运行时配置和业务配置要区分清楚。2. 流程引擎集成SpringBoot 项目里的 Flowable 实战落地2.1 为什么项目里会用到 Flowable搜索热词里出现“springboot使用flowable”说明很多人正在接触这个方向。Flowable 是一个开源的 BPMN 2.0 流程引擎它在 SpringBoot 项目里的典型场景包括审批流、工单流转、合同审批、请假流程。我一度以为这类需求自己写状态机就行一个字段存当前状态写一堆if/else做流转。但真实业务一旦复杂起来状态机就崩了。比如审批流里有会签、或签、逐级审批、驳回、加签、抄送这些用自定义代码实现的话光异常分支就能把人写疯。Flowable 的价值在于把流程定义、流程实例、任务分配、历史记录这些通用能力标准化了。你在 SpringBoot 项目里引入它本质上是在复用一套经过大量生产验证的流程引擎而不是从零造轮子。2.2 集成步骤详解Maven 依赖是最基本的一步dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter/artifactId version6.8.0/version /dependency版本号建议选稳定版不要追最新。之前有个项目用了 6.7.2 的某个小版本和 SpringBoot 2.7 的 Jackson 版本冲突花了大半天排查。引入依赖后启动项目你会发现数据库里自动生成了一堆ACT_开头的表。这是 Flowable 在首次启动时根据配置自动建的表ACT_RE_*流程定义和流程模型的静态信息ACT_RU_*流程实例、任务、变量的运行时信息ACT_HI_*历史数据ACT_GE_*通用数据自动建表是方便但生产环境我建议关闭spring: flowable: database-schema-update: false然后由 DBA 在发布流程中统一执行升级脚本。Flowable 官方文档里其实也推荐生产环境用false避免应用权限过大也避免启动时因为 DDL 锁表影响数据库稳定性。如果你的项目用的是 Flowable 6.x 以上版本还需要注意表前缀配置。默认是ACT_如果公司规定表名必须带业务标识可以设置spring: flowable: table-prefix: biz_这里有个大坑如果自定义了表前缀必须同时配置flowable.idm.enabledfalse否则 Flowable 自带的身份管理模块会尝试访问ACT_ID_*表而按新前缀又找不到启动直接报错。2.3 核心 API 和一条请假流程的落地部署流程定义通常使用RepositoryServiceAutowired private RepositoryService repositoryService; public void deploy(String bpmnPath) { Deployment deployment repositoryService.createDeployment() .addClasspathResource(bpmnPath) .name(请假流程) .deploy(); }启动一个流程实例用RuntimeServiceAutowired private RuntimeService runtimeService; public void start(String processKey, String businessKey, MapString, Object variables) { ProcessInstance instance runtimeService.startProcessInstanceByKey(processKey, businessKey, variables); }之后查询待办任务用TaskServiceAutowired private TaskService taskService; public ListTask getTodoTasks(String assignee) { return taskService.createTaskQuery() .taskAssignee(assignee) .orderByTaskCreateTime().desc() .list(); }你以为这就完了并没有。真实项目里最核心的一步是完成任务而完成任务往往伴随着业务数据变更。这里必须强调事务一致性Flowable 的任务完成操作和你的业务更新必须处在同一个事务里否则就会出现“任务办完了、业务数据没更新”或者“业务更新了、任务卡住”的脏数据。Transactional(rollbackFor Exception.class) public void completeTask(String taskId, String operator, Long bizId, boolean approved) { bizMapper.updateStatus(bizId, approved ? APPROVED : REJECTED); MapString, Object variables new HashMap(); variables.put(approved, approved); taskService.complete(taskId, variables); }Transactional加在方法上两个操作要么一起成功要么一起回滚。这个点我在面试里问过不少候选人很多人能说出 API 的名字但答不上事务问题。请假流程本身不需要写太多代码核心是 BPMN 文件。流程设计建议直接使用 Flowable 官方提供的流程设计器或者 IDEA 插件。画好的流程图放在resources/processes目录下应用启动时 Flowable 会自动部署。2.4 集成 Flowable 后的性能与内存坑Flowable 默认的异步执行器Async Executor会在后台跑定时任务比如定时检查定时事件、补偿任务。如果你的流程里根本没用定时器可以关掉spring: flowable: async-executor-activate: false不关的话它会创建一定数量的线程并且即使没有任务也会定时轮询数据库对流量不大的内部系统来说纯属浪费资源。另一个常见问题是历史表无限增长。Flowable 的ACT_HI_*表会记录所有流程实例的完整轨迹数据量涨得很快。我见过一个运行半年的项目ACT_HI_ACTINST表接近 2000 万行查询性能明显下降。解决方案是在 Flowable 里配置历史数据清理定时任务或者基于应用层定期调 API 清理历史实例。部署前就要想好清理策略不要等线上报警了才处理。还有一个使用习惯争议比较大Flowable 自带的身份管理表。很多项目其实有自己的用户体系完全没必要把用户同步到ACT_ID_*表里。建议关掉 Flowable 的 IDMspring: flowable: idm: enabled: false然后在流程变量里直接传递用户 ID 或用户名或者在任务查询时用自定义的CandidateManager。这样能少维护两张表也让用户体系保持单一来源。3. 自动装配与启动原理面试官最常挖的地方3.1 SpringBootApplication 的真相很多同学写 SpringBoot 项目类上打了SpringBootApplication就完事了但面试官一问“这个注解为什么能启动项目”就卡住。SpringBootApplication其实是三个注解的组合SpringBootConfiguration本质上是Configuration表示这是一个配置类EnableAutoConfiguration开启自动装配ComponentScan扫描当前包及其子包下的组件拆开看就很容易理解为什么主启动类要放在包的顶层。如果放在某个子包里ComponentScan默认扫不到其他兄弟包Controller、Service 全部注入失败。这个“包扫描不生效”的问题在真实项目里真的经常发生第一反应先看启动类位置。EnableAutoConfiguration是自动装配的入口它通过Import(AutoConfigurationImportSelector.class)导入了一个选择器这个选择器会去读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件SpringBoot 2.7 之前是spring.factories把里面列出的所有自动配置类全部加载进来。注意这里用的是“加载进来”面不是“全部生效”。自动配置类上一般都有条件注解比如ConditionalOnClass、ConditionalOnProperty、ConditionalOnMissingBean条件不满足就直接不生效。这就是为什么你引入spring-boot-starter-webSpringBoot 能自动配置出 Tomcat 和 SpringMVC你没引入它就不会配。整套机制的核心思想是“约定优于配置”。3.2 自动装配会不会导致 Bean 冲突很多新人对自动装配有误解以为加载了这么多配置类Bean 一定很多、容易冲突。实际上由于条件注解的存在绝大多数情况下不会冲突。但有一种场景确实会冲突你自己定义了一个ObjectMapperBeanSpringBoot 的JacksonAutoConfiguration也会创建ObjectMapper。这时候两个同类型 Bean 同时存在注入就出问题了。自动装配里的条件注解正好解决了这个问题。JacksonAutoConfiguration里面标了ConditionalOnMissingBean它发现你已经有一个ObjectMapper就会自动“让贤”不再创建默认的。这是面试官很喜欢的考点你可以顺便讲一下ConditionalOnMissingBean的语义当容器中没有某个类型的 Bean 时才创建。理解这套机制之后自定义 Starter 就不是什么高大上的事了。核心就两步写一个自动配置类上面用Configuration和条件注解控制生效范围。在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports里注册这个类。我自己做过一个内部日志组件的 Starter核心就是把日志采集、发送、脱敏这些逻辑封装成自动配置业务项目只要引入依赖加几行配置就能用。做 Starter 的关键不是代码多复杂而是条件注解要写准确否则你这个组件会把所有项目的上下文搅乱。3.3 启动流程里的扩展点SpringBoot 的启动流程可以简化为创建SpringApplication实例、调用run方法、准备环境、创建容器、刷新容器、执行 runner。这句话背出来没用你得知道每个环节能做什么。面试官提“你在项目里怎么在 SpringBoot 启动后做初始化操作”很多人只会想到ApplicationRunner和CommandLineRunner。其实还有一类很常用的接口叫BeanPostProcessor它在每个 Bean 初始化前后做处理。SpringBoot 很多核心功能就是靠它实现的比如AutowiredAnnotationBeanPostProcessor处理Autowired。如果面试时你能说出“自动装配的 Bean 后处理器”和“Runner”的区别会比只背概念的人深入很多。另外一个冷门但好用的扩展点是EnvironmentPostProcessor。它允许你在 Spring 环境准备阶段就修改配置。比如要做配置解密就可以在这里拦截含有密文前缀的配置项通过密钥解密后放回环境里。这才是真正的“程序级”配置处理方式。4. 项目监控与性能调优上线前必须做好的事4.1 Actuator 端点别裸奔SpringBoot Actuator 提供了/actuator/health、/actuator/metrics、/actuator/env等一系列监控端点。开发时全开没毛病但生产环境直接裸奔就麻烦了。/actuator/env会暴露环境变量和配置信息敏感数据一览无余。安全做法是只开放必要的端点并通过management.endpoints.web.exposure.include精确控制management: endpoints: web: exposure: include: health,info,metrics,prometheushealth端点建议把详细信息关掉只返回健康状态避免把数据源连接信息、磁盘信息都暴露出去management: endpoint: health: show-details: never如果你的项目已经集成了 Spring Security切记给/actuator/**配置认证规则。很多人引入 Actuator 之后不做任何安全配置以为“没人知道这个端口”但扫描器一下就能扫出来。4.2 启动慢与运行时性能调优参数SpringBoot 项目启动慢是常态但慢也有慢的排查方向。先看 JVM 参数生产环境建议至少设置初始堆和最大堆一致避免运行时动态扩缩容带来停顿java -Xms2g -Xmx2g -jar app.jar如果服务器内存充裕直接给足堆内存。我之前遇到过一个小服务默认最大堆只有服务器物理内存的 1/4流量稍微一大就频繁 Full GC。调整 Xmx 之后接口耗时直线下降。再看 Tomcat 线程池SpringBoot 内置 Tomcat 的默认配置对高并发场景不一定够用。常见调整参数server: tomcat: threads: max: 400 min-spare: 50 accept-count: 200 max-connections: 10000这里要理解一个关系max-threads是能同时处理请求的线程数上限accept-count是等待队列长度max-connections是操作系统层面接收连接的个数。如果三者配得不对比如线程数很小但队列很长请求排队时间会非常长用户感知就是“卡死了”。线上调整这些参数务必先压测不要凭感觉拍脑袋。4.3 异步任务与线程池配置SpringBoot 项目里Async注解很常用但我发现很多人不知道它默认走的是SimpleAsyncTaskExecutor这个执行器压根不复用线程而是每次都新建线程资源消耗极大生产环境千万别直接这么用。正经的做法是自定义线程池Configuration public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(100); executor.setThreadNamePrefix(async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }几个参数怎么定核心线程数按照“任务类型是 CPU 密集型还是 IO 密集型”来定。IO 密集型任务比如查数据库、调远程接口核心线程数可以设置为核心数 * 2 左右因为大部分时间线程都在等待。CallerRunsPolicy是我推荐的重试策略队列满了之后新任务由提交线程自己执行不会把任务直接丢掉。AbortPolicy会直接抛异常用之前要想清楚业务是否能接受。顺带提一个排查陷阱如果你在一个事务方法内部调用同类里的另一个Async方法Spring 的代理机制不会生效因为外部调用没有经过代理对象。这就是常说的“自调用失效”问题。要让异步生效需要从外部注入代理对象或者用AopContext.currentProxy()。这个坑不亲自踩一次光看文档很难记住。5. 面试考点与项目经验速查5.1 SpringBoot 高频面试题整理结合这几年的面试经验我把 SpringBoot 方向高频问题拢成一张表问题核心答法SpringBoot 和 Spring 的区别SpringBoot 基于 Spring简化了配置和部署内嵌 Web 容器自动装配自动装配原理EnableAutoConfiguration AutoConfigurationImportSelector 条件注解内嵌 Tomcat 原理spring-boot-starter-web 引入 tomcat-embed-core通过工厂创建 WebServer如何自定义 Starter自动配置类 AutoConfiguration.imports 注册 条件注解配置文件优先级命令行 系统属性 环境变量 profile 配置 默认配置Bean 生命周期实例化、属性填充、Aware、BeanPostProcessor、init、使用、销毁Actuator 怎么用端点暴露、监控指标、健康检查、暴露控制与安全这里我想多说一嘴答这些问题别只背结论。面试官问你自动装配原理你哪怕把AutoConfigurationImportSelector的类名说出来了但说不清条件注解怎么控制生效依然拿不到高分。回答的时候要有“骨架细节”先给整体链路再挑一个点展开。有一个容易被问倒的细节是循环依赖。SpringBoot 默认支持单例 Bean 的循环依赖三级缓存解决。但如果构造器注入方式存在循环依赖Spring 是解决不了的只能报错。建议代码里尽量避免循环依赖不要依赖框架帮你兜底。5.2 简历上怎么写 SpringBoot 项目经验写 SpringBoot 项目经验最忌讳的写法就是“熟悉 SpringBoot、使用 SpringBoot 开发了 XX 系统”。这种描述等于没写。比较好的写法是突出两个维度一是技术深度二是业务复杂度。技术深度可以写“基于 SpringBoot 自动装配机制自定义通用日志 Starter覆盖 XX 个微服务”业务复杂度可以写“基于 Flowable 流程引擎实现多级审批流支持会签、驳回、加签累计承载 XX 万条流程实例”。面试官看到这种描述一般会顺着追问“自动装配怎么做”“Flowable 的驳回怎么实现”“流程实例数据量这么大怎么优化”。这些如果你都能答上来项目经历就真正变成了加分的面试素材。5.3 真实项目里的问题排查速查表最后放一份我自己的问题排查速查表平时遇到同类问题能少走很多弯路。现象排查方向配置不生效检查是否存在更高优先级来源命令行、环境变量、profile接口偶现超时数据库慢查询、连接池不足、Full GC、外部依赖延迟任务卡住不流转确认事务是否统一Flowable 异步执行器是否开启应用启动后端口被占用lsof -i :8080或netstat -ano找占用进程Bean 注入报错检查启动类是否在包顶层有没有循环依赖条件注解适不适用内存持续上涨堆 dump 分析重点看是否有大对象、缓存泄漏、线程池堆积Actuator 端点 404确认暴露配置是否正确Spring Security 是否拦截并重定向很多问题并不是 SpringBoot 本身的 bug而是使用方式不对。排查的时候不要一上来就怀疑框架先看自己的配置、依赖、调用方式大部分问题都能从这几个角度找到答案。我个人在实际项目里最深刻的体会是SpringBoot 的入门门槛确实低但真正拉开差距的是你对自动装配、启动流程、配置体系这些底层机制的理解程度。框架帮你屏蔽了复杂性但如果你完全不懂背后的原理遇到问题只能靠重启、靠猜。把这篇里提到的配置、Flowable 集成、自动装配和调优思路顺着源码再走一遍比你刷十个 Demo 都有用。最后再分享一个小技巧遇到任何诡异的问题先开 debug 日志再复现一次通常日志里会把真正的线索带到你面前。不要急着改代码先看清楚现场。
从第二期开始说这次聊聊 SpringBoot 项目里真正绕不开的东西上一篇把 SpringBoot 的项目骨架、分层结构和基础注解讲完之后不少朋友在后台留言说最想看的还是“项目里真正踩过的坑”和“面试时被问到的点”。这一篇我就顺着这个思路把配置体系、Flowable 流程引擎集成、自动装配原理、监控调优这四块展开讲。内容都是我在实际 SpringBoot 项目里反复碰过、排查过、优化过的东西不是背书式的官方文档复述。这套内容适合谁适合已经能跑起一个 SpringBoot Demo、但一进真实项目就发懵的同学也适合准备跳槽、需要把 SpringBoot 项目经验讲出深度的开发。全文没有太多废话每一节都能直接对应到项目开发和面试场景。1. 从项目视角重新理解 SpringBoot 配置体系1.1 配置优先级与常见坑SpringBoot 的配置优先级是面试里特别爱考、项目里特别容易出问题的点。官方文档给了一大堆顺序但实际开发中你只要记住这条核心链命令行参数 Java 系统属性 操作系统环境变量 application-{profile}.yml application.yml SpringApplication.setDefaultProperties我见过很多次“配置不生效”的排查过程最后发现是启动脚本里加了--server.port8081而配置文件里写的是server.port8080结果怎么改 yml 都没用。这是典型的命令行参数优先级最高导致的。另一个容易踩的坑是 profile 文件的加载逻辑。application-dev.yml不会自动生效必须在application.yml里配置spring.profiles.activedev或者通过启动参数--spring.profiles.activedev指定。如果你的环境没有显式激活 profileSpringBoot 只会加载默认的application.yml所有 profile 相关的配置全部不生效。还有一个注意点同一份配置里spring.config.additional-location和spring.config.location这两个参数很容易混淆。前者是追加外部配置目录后者是替换默认配置位置。生产环境一般只用前者因为后者会把 jar 包内置的配置文件整个干掉稍不注意就连数据源都起不来。1.2 自定义配置绑定ConfigurationProperties 比 Value 好用在哪很多项目里还在大量使用Value(${xxx.yyy})注入配置这个写法本身没毛病但当你有一组关联配置时就会变得非常痛苦。比如配置一个短信渠道商的信息sms: provider: aliyun access-key-id: xxx access-key-secret: xxx sign-name: 测试签名 template-code: SMS_123456用Value的话你得写四个字段每个都要写注解而且字段类型不会自动做复杂转换。用ConfigurationProperties就清爽很多Component ConfigurationProperties(prefix sms) public class SmsProperties { private String provider; private String accessKeyId; private String accessKeySecret; private String signName; private String templateCode; // getter/setter 省略 }这里有个关键点access-key-id这种 kebab-case 写法会自动映射到accessKeyId字段这是 SpringBoot 的宽松绑定规则。但如果你用Value就必须严格写Value(${sms.access-key-id})字段名和配置文件里的写法完全一致才行宽松规则不生效。还有一个进阶用法是把配置绑定做到不可变对象上用ConstructorBindingConfigurationProperties(prefix sms) public class SmsProperties { private final String provider; private final String accessKeyId; // 构造方法省略 }这样配置类就是只读的从设计角度更安全也符合依赖注入的思路。我去年把一个老项目的Value全部迁到ConfigurationProperties之后配置类清晰了很多单元测试也好写多了。1.3 多环境配置怎么落地现实项目里至少有三套环境开发、测试、生产。如果一个 yml 文件里塞满了各种环境的地址切换部署的时候改来改去迟早出事。推荐的做法是拆文件application.yml application-dev.yml application-test.yml application-prod.ymlapplication.yml里只放公共配置比如应用名、编码、日志级别兜底。环境相关的内容全部放到对应 profile 文件里。然后通过启动参数指定环境比如测试环境启动命令java -jar demo.jar --spring.profiles.activetest这里我特别想提醒一个容易漏的配置环境标识要尽量早地暴露出来。我习惯在application.yml里加上一个自定义配置app: env: profile.active结合 Maven 的 profile 做资源过滤构建时就确定环境标识。这样在日志里能直接看到当前是什么环境避免“明明部署的是生产包结果连的是测试库”这种低级事故。多环境配置的另一个坑是数据库密码。很多团队把明文密码写在application-prod.yml里提交到 Git这是很大的安全隐患。至少要用环境变量占位符spring: datasource: password: ${DB_PASSWORD}这样代码仓库里不会有真实生产密码部署时由运维在服务器环境变量里注入。如果你的团队有条件可以接配置中心但也不要因为有了配置中心就把所有配置都扔进去应用自身的运行时配置和业务配置要区分清楚。2. 流程引擎集成SpringBoot 项目里的 Flowable 实战落地2.1 为什么项目里会用到 Flowable搜索热词里出现“springboot使用flowable”说明很多人正在接触这个方向。Flowable 是一个开源的 BPMN 2.0 流程引擎它在 SpringBoot 项目里的典型场景包括审批流、工单流转、合同审批、请假流程。我一度以为这类需求自己写状态机就行一个字段存当前状态写一堆if/else做流转。但真实业务一旦复杂起来状态机就崩了。比如审批流里有会签、或签、逐级审批、驳回、加签、抄送这些用自定义代码实现的话光异常分支就能把人写疯。Flowable 的价值在于把流程定义、流程实例、任务分配、历史记录这些通用能力标准化了。你在 SpringBoot 项目里引入它本质上是在复用一套经过大量生产验证的流程引擎而不是从零造轮子。2.2 集成步骤详解Maven 依赖是最基本的一步dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter/artifactId version6.8.0/version /dependency版本号建议选稳定版不要追最新。之前有个项目用了 6.7.2 的某个小版本和 SpringBoot 2.7 的 Jackson 版本冲突花了大半天排查。引入依赖后启动项目你会发现数据库里自动生成了一堆ACT_开头的表。这是 Flowable 在首次启动时根据配置自动建的表ACT_RE_*流程定义和流程模型的静态信息ACT_RU_*流程实例、任务、变量的运行时信息ACT_HI_*历史数据ACT_GE_*通用数据自动建表是方便但生产环境我建议关闭spring: flowable: database-schema-update: false然后由 DBA 在发布流程中统一执行升级脚本。Flowable 官方文档里其实也推荐生产环境用false避免应用权限过大也避免启动时因为 DDL 锁表影响数据库稳定性。如果你的项目用的是 Flowable 6.x 以上版本还需要注意表前缀配置。默认是ACT_如果公司规定表名必须带业务标识可以设置spring: flowable: table-prefix: biz_这里有个大坑如果自定义了表前缀必须同时配置flowable.idm.enabledfalse否则 Flowable 自带的身份管理模块会尝试访问ACT_ID_*表而按新前缀又找不到启动直接报错。2.3 核心 API 和一条请假流程的落地部署流程定义通常使用RepositoryServiceAutowired private RepositoryService repositoryService; public void deploy(String bpmnPath) { Deployment deployment repositoryService.createDeployment() .addClasspathResource(bpmnPath) .name(请假流程) .deploy(); }启动一个流程实例用RuntimeServiceAutowired private RuntimeService runtimeService; public void start(String processKey, String businessKey, MapString, Object variables) { ProcessInstance instance runtimeService.startProcessInstanceByKey(processKey, businessKey, variables); }之后查询待办任务用TaskServiceAutowired private TaskService taskService; public ListTask getTodoTasks(String assignee) { return taskService.createTaskQuery() .taskAssignee(assignee) .orderByTaskCreateTime().desc() .list(); }你以为这就完了并没有。真实项目里最核心的一步是完成任务而完成任务往往伴随着业务数据变更。这里必须强调事务一致性Flowable 的任务完成操作和你的业务更新必须处在同一个事务里否则就会出现“任务办完了、业务数据没更新”或者“业务更新了、任务卡住”的脏数据。Transactional(rollbackFor Exception.class) public void completeTask(String taskId, String operator, Long bizId, boolean approved) { bizMapper.updateStatus(bizId, approved ? APPROVED : REJECTED); MapString, Object variables new HashMap(); variables.put(approved, approved); taskService.complete(taskId, variables); }Transactional加在方法上两个操作要么一起成功要么一起回滚。这个点我在面试里问过不少候选人很多人能说出 API 的名字但答不上事务问题。请假流程本身不需要写太多代码核心是 BPMN 文件。流程设计建议直接使用 Flowable 官方提供的流程设计器或者 IDEA 插件。画好的流程图放在resources/processes目录下应用启动时 Flowable 会自动部署。2.4 集成 Flowable 后的性能与内存坑Flowable 默认的异步执行器Async Executor会在后台跑定时任务比如定时检查定时事件、补偿任务。如果你的流程里根本没用定时器可以关掉spring: flowable: async-executor-activate: false不关的话它会创建一定数量的线程并且即使没有任务也会定时轮询数据库对流量不大的内部系统来说纯属浪费资源。另一个常见问题是历史表无限增长。Flowable 的ACT_HI_*表会记录所有流程实例的完整轨迹数据量涨得很快。我见过一个运行半年的项目ACT_HI_ACTINST表接近 2000 万行查询性能明显下降。解决方案是在 Flowable 里配置历史数据清理定时任务或者基于应用层定期调 API 清理历史实例。部署前就要想好清理策略不要等线上报警了才处理。还有一个使用习惯争议比较大Flowable 自带的身份管理表。很多项目其实有自己的用户体系完全没必要把用户同步到ACT_ID_*表里。建议关掉 Flowable 的 IDMspring: flowable: idm: enabled: false然后在流程变量里直接传递用户 ID 或用户名或者在任务查询时用自定义的CandidateManager。这样能少维护两张表也让用户体系保持单一来源。3. 自动装配与启动原理面试官最常挖的地方3.1 SpringBootApplication 的真相很多同学写 SpringBoot 项目类上打了SpringBootApplication就完事了但面试官一问“这个注解为什么能启动项目”就卡住。SpringBootApplication其实是三个注解的组合SpringBootConfiguration本质上是Configuration表示这是一个配置类EnableAutoConfiguration开启自动装配ComponentScan扫描当前包及其子包下的组件拆开看就很容易理解为什么主启动类要放在包的顶层。如果放在某个子包里ComponentScan默认扫不到其他兄弟包Controller、Service 全部注入失败。这个“包扫描不生效”的问题在真实项目里真的经常发生第一反应先看启动类位置。EnableAutoConfiguration是自动装配的入口它通过Import(AutoConfigurationImportSelector.class)导入了一个选择器这个选择器会去读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件SpringBoot 2.7 之前是spring.factories把里面列出的所有自动配置类全部加载进来。注意这里用的是“加载进来”面不是“全部生效”。自动配置类上一般都有条件注解比如ConditionalOnClass、ConditionalOnProperty、ConditionalOnMissingBean条件不满足就直接不生效。这就是为什么你引入spring-boot-starter-webSpringBoot 能自动配置出 Tomcat 和 SpringMVC你没引入它就不会配。整套机制的核心思想是“约定优于配置”。3.2 自动装配会不会导致 Bean 冲突很多新人对自动装配有误解以为加载了这么多配置类Bean 一定很多、容易冲突。实际上由于条件注解的存在绝大多数情况下不会冲突。但有一种场景确实会冲突你自己定义了一个ObjectMapperBeanSpringBoot 的JacksonAutoConfiguration也会创建ObjectMapper。这时候两个同类型 Bean 同时存在注入就出问题了。自动装配里的条件注解正好解决了这个问题。JacksonAutoConfiguration里面标了ConditionalOnMissingBean它发现你已经有一个ObjectMapper就会自动“让贤”不再创建默认的。这是面试官很喜欢的考点你可以顺便讲一下ConditionalOnMissingBean的语义当容器中没有某个类型的 Bean 时才创建。理解这套机制之后自定义 Starter 就不是什么高大上的事了。核心就两步写一个自动配置类上面用Configuration和条件注解控制生效范围。在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports里注册这个类。我自己做过一个内部日志组件的 Starter核心就是把日志采集、发送、脱敏这些逻辑封装成自动配置业务项目只要引入依赖加几行配置就能用。做 Starter 的关键不是代码多复杂而是条件注解要写准确否则你这个组件会把所有项目的上下文搅乱。3.3 启动流程里的扩展点SpringBoot 的启动流程可以简化为创建SpringApplication实例、调用run方法、准备环境、创建容器、刷新容器、执行 runner。这句话背出来没用你得知道每个环节能做什么。面试官提“你在项目里怎么在 SpringBoot 启动后做初始化操作”很多人只会想到ApplicationRunner和CommandLineRunner。其实还有一类很常用的接口叫BeanPostProcessor它在每个 Bean 初始化前后做处理。SpringBoot 很多核心功能就是靠它实现的比如AutowiredAnnotationBeanPostProcessor处理Autowired。如果面试时你能说出“自动装配的 Bean 后处理器”和“Runner”的区别会比只背概念的人深入很多。另外一个冷门但好用的扩展点是EnvironmentPostProcessor。它允许你在 Spring 环境准备阶段就修改配置。比如要做配置解密就可以在这里拦截含有密文前缀的配置项通过密钥解密后放回环境里。这才是真正的“程序级”配置处理方式。4. 项目监控与性能调优上线前必须做好的事4.1 Actuator 端点别裸奔SpringBoot Actuator 提供了/actuator/health、/actuator/metrics、/actuator/env等一系列监控端点。开发时全开没毛病但生产环境直接裸奔就麻烦了。/actuator/env会暴露环境变量和配置信息敏感数据一览无余。安全做法是只开放必要的端点并通过management.endpoints.web.exposure.include精确控制management: endpoints: web: exposure: include: health,info,metrics,prometheushealth端点建议把详细信息关掉只返回健康状态避免把数据源连接信息、磁盘信息都暴露出去management: endpoint: health: show-details: never如果你的项目已经集成了 Spring Security切记给/actuator/**配置认证规则。很多人引入 Actuator 之后不做任何安全配置以为“没人知道这个端口”但扫描器一下就能扫出来。4.2 启动慢与运行时性能调优参数SpringBoot 项目启动慢是常态但慢也有慢的排查方向。先看 JVM 参数生产环境建议至少设置初始堆和最大堆一致避免运行时动态扩缩容带来停顿java -Xms2g -Xmx2g -jar app.jar如果服务器内存充裕直接给足堆内存。我之前遇到过一个小服务默认最大堆只有服务器物理内存的 1/4流量稍微一大就频繁 Full GC。调整 Xmx 之后接口耗时直线下降。再看 Tomcat 线程池SpringBoot 内置 Tomcat 的默认配置对高并发场景不一定够用。常见调整参数server: tomcat: threads: max: 400 min-spare: 50 accept-count: 200 max-connections: 10000这里要理解一个关系max-threads是能同时处理请求的线程数上限accept-count是等待队列长度max-connections是操作系统层面接收连接的个数。如果三者配得不对比如线程数很小但队列很长请求排队时间会非常长用户感知就是“卡死了”。线上调整这些参数务必先压测不要凭感觉拍脑袋。4.3 异步任务与线程池配置SpringBoot 项目里Async注解很常用但我发现很多人不知道它默认走的是SimpleAsyncTaskExecutor这个执行器压根不复用线程而是每次都新建线程资源消耗极大生产环境千万别直接这么用。正经的做法是自定义线程池Configuration public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(100); executor.setThreadNamePrefix(async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }几个参数怎么定核心线程数按照“任务类型是 CPU 密集型还是 IO 密集型”来定。IO 密集型任务比如查数据库、调远程接口核心线程数可以设置为核心数 * 2 左右因为大部分时间线程都在等待。CallerRunsPolicy是我推荐的重试策略队列满了之后新任务由提交线程自己执行不会把任务直接丢掉。AbortPolicy会直接抛异常用之前要想清楚业务是否能接受。顺带提一个排查陷阱如果你在一个事务方法内部调用同类里的另一个Async方法Spring 的代理机制不会生效因为外部调用没有经过代理对象。这就是常说的“自调用失效”问题。要让异步生效需要从外部注入代理对象或者用AopContext.currentProxy()。这个坑不亲自踩一次光看文档很难记住。5. 面试考点与项目经验速查5.1 SpringBoot 高频面试题整理结合这几年的面试经验我把 SpringBoot 方向高频问题拢成一张表问题核心答法SpringBoot 和 Spring 的区别SpringBoot 基于 Spring简化了配置和部署内嵌 Web 容器自动装配自动装配原理EnableAutoConfiguration AutoConfigurationImportSelector 条件注解内嵌 Tomcat 原理spring-boot-starter-web 引入 tomcat-embed-core通过工厂创建 WebServer如何自定义 Starter自动配置类 AutoConfiguration.imports 注册 条件注解配置文件优先级命令行 系统属性 环境变量 profile 配置 默认配置Bean 生命周期实例化、属性填充、Aware、BeanPostProcessor、init、使用、销毁Actuator 怎么用端点暴露、监控指标、健康检查、暴露控制与安全这里我想多说一嘴答这些问题别只背结论。面试官问你自动装配原理你哪怕把AutoConfigurationImportSelector的类名说出来了但说不清条件注解怎么控制生效依然拿不到高分。回答的时候要有“骨架细节”先给整体链路再挑一个点展开。有一个容易被问倒的细节是循环依赖。SpringBoot 默认支持单例 Bean 的循环依赖三级缓存解决。但如果构造器注入方式存在循环依赖Spring 是解决不了的只能报错。建议代码里尽量避免循环依赖不要依赖框架帮你兜底。5.2 简历上怎么写 SpringBoot 项目经验写 SpringBoot 项目经验最忌讳的写法就是“熟悉 SpringBoot、使用 SpringBoot 开发了 XX 系统”。这种描述等于没写。比较好的写法是突出两个维度一是技术深度二是业务复杂度。技术深度可以写“基于 SpringBoot 自动装配机制自定义通用日志 Starter覆盖 XX 个微服务”业务复杂度可以写“基于 Flowable 流程引擎实现多级审批流支持会签、驳回、加签累计承载 XX 万条流程实例”。面试官看到这种描述一般会顺着追问“自动装配怎么做”“Flowable 的驳回怎么实现”“流程实例数据量这么大怎么优化”。这些如果你都能答上来项目经历就真正变成了加分的面试素材。5.3 真实项目里的问题排查速查表最后放一份我自己的问题排查速查表平时遇到同类问题能少走很多弯路。现象排查方向配置不生效检查是否存在更高优先级来源命令行、环境变量、profile接口偶现超时数据库慢查询、连接池不足、Full GC、外部依赖延迟任务卡住不流转确认事务是否统一Flowable 异步执行器是否开启应用启动后端口被占用lsof -i :8080或netstat -ano找占用进程Bean 注入报错检查启动类是否在包顶层有没有循环依赖条件注解适不适用内存持续上涨堆 dump 分析重点看是否有大对象、缓存泄漏、线程池堆积Actuator 端点 404确认暴露配置是否正确Spring Security 是否拦截并重定向很多问题并不是 SpringBoot 本身的 bug而是使用方式不对。排查的时候不要一上来就怀疑框架先看自己的配置、依赖、调用方式大部分问题都能从这几个角度找到答案。我个人在实际项目里最深刻的体会是SpringBoot 的入门门槛确实低但真正拉开差距的是你对自动装配、启动流程、配置体系这些底层机制的理解程度。框架帮你屏蔽了复杂性但如果你完全不懂背后的原理遇到问题只能靠重启、靠猜。把这篇里提到的配置、Flowable 集成、自动装配和调优思路顺着源码再走一遍比你刷十个 Demo 都有用。最后再分享一个小技巧遇到任何诡异的问题先开 debug 日志再复现一次通常日志里会把真正的线索带到你面前。不要急着改代码先看清楚现场。
