简介一套基于SpringBoot的智慧养老平台完整Java源码面向计算机、电子信息工程等专业学习者适合作为毕业设计、课程设计及期末大作业。系统采用B/S架构与MVC模式整合SpringBoot、Mybatis、Ajax、Vue等技术栈覆盖前端交互、后端服务与数据库设计可在Windows/Mac环境下配合JDK1.8、Mysql5.7、Maven3.6快速运行。压缩包共包含950个文件总体积17.83MB以Java源文件195个、Vue组件65个、JavaScript脚本164个、HTML页面69个及CSS样式53个为主并附带数据库脚本、配置文件与启动脚本目录划分明确便于学习和二次开发。已有335人学习下载所有源码经过严格测试可直接部署使用。这套代码能帮助读者快速理解SpringBoot实际项目的完整结构掌握前后端分离开发与养老服务业务逻辑的实现思路是提升工程实践能力的实用参考。1. Java智慧养老平台代码的核心是三条数据闭环不是一个后台管理系统一位养老机构的负责人在项目启动会上说平台要能看大屏、能看监控、能派单、家属能收到推送。听起来是标准的管理系统可一旦设备数据接入问题立刻就变了老人离床报警和SOS按钮可能一秒内上报多次护工抢单并发来了家属通知要等所有渠道都发送完再返回。Java智慧养老平台代码真正的复杂度不在增删改查而在「老人轨迹、服务工单、健康时序」这三条闭环数据如何被正确建模和处理。如果只把平台当作按角色分菜单的CRUD大概率会在联调阶段被真实的时序数据和高频上报打穿。这篇博客不贴完整源码而是把做这个标题最常见的落地路径讲清楚从ER设计、工单状态机到设备上报的防抖和并发通知再落到部署和压测参数。适合正在设计或维护养老类平台后端的Java工程师也适合团队里负责技术选型的人用来校对方案的边界。2. Java智慧养老平台代码的选型与ER设计先定表再写逻辑2.1 单体优先Spring Boot 3 MySQL 8 足够支撑两千张床位养老平台的并发量本质上是低频写、中频读几千名老人、几百名护工、每天几万条健康指标。作为技术负责人我一般不会为了这种体量引入微服务和消息中间件因为事务的复杂度远大于流量的复杂度。一个工单从创建到结算涉及订单、护工、回访、结算四个表用单体里的本地事务和数据库锁就能解决拆成微服务反而要处理分布式事务和最终一致性是给自己挖坑。建议技术栈固定为 Java 17、Spring Boot 3.x、MyBatis-Plus、MySQL 8、Redis 7。前端用 Vue3 或其他管理端框架都行和本标题关系不大不在这里展开。依赖坐标用一个最小骨架parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-spring-boot3-starter/artifactId version3.5.7/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency /dependenciesMyBatis-Plus 在 Java 智慧养老平台代码里主要价值是单表 CRUD 不用写 SQL工单查询这种多条件场景仍需要手写 XML。Redis 的用途是防抖、计数和分布式锁不是为了缓存热数据健康数据本身更适合查 MySQL 的分表。选型时把这些定位说清楚后面写代码就不会纠结技术栈是否够强。2.2 六张核心表把老人、护工、服务单、健康指标分开建模设计数据库时最容易犯的错是给平台建一张巨大的「用户表」把老人、家属、护工、管理员全塞进去。正确做法是把组织身份和业务数据分开老人是档案主数据护工是服务资源家属只作为关联通知对象。下面的表结构是 Java 智慧养老平台代码里相对通用的起步形态表名业务含义关键字段elderly_member老人档案id、name、room_no、bed_no、level、statuscaregiver护工档案id、name、phone、skills、service_scopeservice_order服务工单id、elderly_id、order_no、type、status、sos_flagorder_track工单流转记录id、order_id、from_status、to_status、operator_idhealth_metric健康指标id、elderly_id、metric_type、value、collected_atsos_alert紧急呼叫事件id、elderly_id、source、alert_time、handle_time其中 service_order 是核心它把老人的服务需求和护工的执行动作串起来order_track 是工单状态机的审计日志每次状态变更都插入一条方便追溯责任。health_metric 和 sos_alert 是设备侧的写模型特点是写入量大、几乎不更新、按时间范围查询这类表在后续章节里再做按月分表处理这里先保留逻辑外键。elderly_id 处不做物理外键理由是业务上需要支持批量导入和归档物理外键在大批量写入时会拖慢性能。一致性交给应用层保障也就是在创建工单时显式校验老人和护工的存在性。这个取舍在 Java 智慧养老平台代码场景里很常见数据库只需要承担存储和索引不需要承担业务规则。2.3 用 Java 工具自动生成数据库设计文档避免文档和表结构脱节项目迭代到第二个月数据库设计文档往往就没人维护了。常见做法是用开源工具从数据库元数据自动生成 Markdown 或 HTML 文档。这里推荐 screw数据库表结构文档生成工具它支持 MySQL、PostgreSQL能直接生成包含表注释、列注释、索引信息的文档。在测试环境执行一次输出产物丢到项目 docs 目录里配合接口文档就能覆盖大部分交接场景。// 直接用 main 方法触发无需启动 Spring 容器 public class DbDocGenerator { public static void main(String[] args) { String url jdbc:mysql://localhost:3306/elderly_care?useUnicodetruecharacterEncodingutf8; Configuration config Configuration.builder() .driver(com.mysql.cj.jdbc.Driver) .url(url) .username(root) .password(root) .build(); new DocumentGenerate(config, new ExecutePropel( ProcessConfig.builder() .designatedTableName(Arrays.asList(elderly_member, service_order)) .build() ), new MarkdownBuilder()).execute(); } }这段代码里的designatedTableName参数用来指定要导出的表不传则导出全部表。用 MarkdownBuilder 生成的文档适合放 Git 仓库评审如果在交付时要给客户看换成 HtmlBuilder 会更美观。关键点是把这个工具接进 CI 流程或至少放进项目根目录每次表结构变更顺手跑一次才能避免文档过期。3. 工单闭环是Java智慧养老平台代码的核心业务状态机和动态SQL要一起设计3.1 用枚举和事件驱动实现工单状态流转别用 if else 散落一地工单是这个平台里业务规则最密集的地方待派单、已派单、服务中、待回访、已完成、已取消。每个状态能做什么操作、谁能操作、状态怎么流转必须收敛到一处否则上线三个月后会变成维护灾难。用枚举实现状态机把当前状态、目标状态和动作绑定在事务方法里是常见的可靠做法public enum OrderStatus { PENDING_ASSIGN(0, 待派单), ASSIGNED(1, 已派单), SERVING(2, 服务中), PENDING_REVIEW(3, 待回访), COMPLETED(4, 已完成), CANCELED(5, 已取消); private final int code; private final String desc; public boolean canTransferTo(OrderStatus target) { // 定义允许的流转路径防住非法跳转 return switch (this) { case PENDING_ASSIGN - target ASSIGNED || target CANCELED; case ASSIGNED - target SERVING || target CANCELED; case SERVING - target PENDING_REVIEW || target CANCELED; case PENDING_REVIEW - target COMPLETED; default - false; }; } }这种写法把「谁能干」的校验放在 Service 层调用canTransferTo职责清晰且方便写单元测试。switch表达式中没有 case 的状态一律不接收流转包括已完成状态不允许再回退。八股文里常考的状态模式在这里的真正意义不是套设计模式而是把规则集中让新同学改需求时不用满项目找if。3.2 派单接口的事务与防重Transactional 要和分布式锁配合派单是高频操作护工在 App 抢单时多个请求可能同时命中同一个工单。单纯用数据库乐观锁可以防超卖但 Java 智慧养老平台代码里还可能涉及调第三方短信和生成派单记录这些动作不适合只靠UPDATE count count - 1去约束。推荐组合方案Redis 分布式锁控制并发数据库状态字段做兜底事务包裹业务写操作Transactional(rollbackFor Exception.class) public boolean dispatchOrder(Long orderId, Long caregiverId) { String lockKey lock:order: orderId; boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (!locked) { throw new BizException(工单正在处理中请勿重复操作); } try { // 数据库兜底必须是待派单状态才允许派单 int updated orderMapper.casDispatch(orderId, caregiverId); if (updated 0) { throw new BizException(工单状态已变化派单失败); } orderTrackMapper.insert(new OrderTrack(orderId, OrderStatus.PENDING_ASSIGN, OrderStatus.ASSIGNED, caregiverId)); return true; } finally { stringRedisTemplate.delete(lockKey); } }setIfAbsent是加锁的原子操作设置 10 秒过期防止锁未释放导致死锁。这里有个细节业务执行时间超过锁过期时间时 A 线程的锁会被 B 线程覆盖所以锁过期时间要远大于业务耗时。casDispatch是自定义 SQL核心是UPDATE service_order SET status1 WHERE id? AND status0影响行数为 0 时说明并发下状态已被其他请求更新这种写法即使 Redis 锁失效数据库条件更新也会拦截重复派单。3.3 Java对MySQL的搜索语句动态SQL处理多条件筛选平台管理后台的工单查询往往要同时支持老人姓名、护工姓名、时间范围、状态多个筛选条件用 Java 的 if 拼 SQL 很容易造成 SQL 注入或语法错误。标准做法是 MyBatis XML 里的动态标签把条件判断交给框架处理select idsearchOrders resultTypecom.demo.order.vo.OrderVO SELECT o.id, o.order_no, e.name AS elderly_name, c.name AS caregiver_name, o.status, o.created_at FROM service_order o LEFT JOIN elderly_member e ON o.elderly_id e.id LEFT JOIN caregiver c ON o.caregiver_id c.id where if testparam.status ! null AND o.status #{param.status} /if if testparam.elderlyName ! null and param.elderlyName ! AND e.name LIKE CONCAT(%, #{param.elderlyName}, %) /if if testparam.startTime ! null AND o.created_at gt; #{param.startTime} /if if testparam.endTime ! null AND o.created_at lt; #{param.endTime} /if /where ORDER BY o.created_at DESC LIMIT #{param.offset}, #{param.pageSize} /selectwhere标签会自动去掉第一个条件前多余的 AND不需要在业务代码里手动处理。LIKE 查询的CONCAT拼接能避免#{param.elderlyName}直接拼进字符串带来的注入风险。pageSize 建议限制最大值 100防止有人调LIMIT 999999把数据库拖垮。查询返回的 VO 不直接映射实体因为需要关联老人和护工的姓名字段。4. 健康设备上报与SOS呼救的并发处理Redisincrement的坑要提前排4.1 健康指标按月分表MyBatis-Plus 动态表名实现health_metric 表每天写入量取决于设备接入量一张床的智能床垫每 5 分钟上报一条体动和心率数据2000 张床一天就是约 60 万条。单表超过几百万行后按时间范围查询会明显变慢所以要在设计初期就按月分表表名类似health_metric_202506。用 MyBatis-Plus 的DynamicTableNameInnerInterceptor可以按当前月份自动路由不需要在业务代码里写死表名Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); DynamicTableNameInnerInterceptor dynamic new DynamicTableNameInnerInterceptor(); dynamic.setTableNameHandler((sql, tableName) - { if (health_metric.equals(tableName)) { return tableName _ LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMM)); } return tableName; }); interceptor.addInnerInterceptor(dynamic); return interceptor; } }这里的拦截器会在执行 SQL 前把表名替换为带后缀的物理表。需要注意这个处理器是应用级全局的对于需要跨月查询报表的场景要再手写 SQL 查多张表做 UNION ALL。分表后建表语句里的索引也要跟着调整推荐联合索引(elderly_id, collected_at)按老人查询时间范围的频率远高于跨所有老人查询。设备插入采用批量写入优化MyBatis-Plus 的saveBatch默认分批提交建议每批 500 条过高会导致单条 SQL 超过 MySQL 的max_allowed_packet。写入失败时不要整批重试先按设备 ID 分组找出失败的数据再补写避免重复消费时把完整批次再次提交。4.2 用 Redis 做SOS防抖和计数increment的类型坑要处理SOS 呼救按钮一旦按下设备往往会连续上报多次如果每次都触发一次工单创建和家属短信后果是灾难性的。常规方案是给同一老人设置一个 10 秒的防抖标记标记存在时直接丢弃同时用计数器记录上报次数作为冗余追踪信息public boolean tryAcquireSos(Long elderlyId) { String dedupKey sos:dedup: elderlyId; Boolean success stringRedisTemplate.opsForValue() .setIfAbsent(dedupKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(success)) { // 首次上报计数归 1 stringRedisTemplate.opsForValue().set(sos:cnt: elderlyId, 1); return true; } // 10 秒内重复上报计数加一 try { stringRedisTemplate.opsForValue() .increment(sos:cnt: elderlyId); } catch (Exception ex) { // 计数失败只记录日志不影响防抖主流程 log.warn(increment sos count failed: {}, ex.getMessage()); } return false; }这里必须用stringRedisTemplate而不是默认的redisTemplate否则很容易踩到increment()报错的坑使用 JDK 序列化器时存进去的字符串读到的是 byte[]increment()执行时报ClassCastException或提示value is not an integer or out of range。用StringRedisTemplatekey 和 value 都是字符串Redis 服务端会把字符串当整数处理避免序列化器带来的类型问题。防抖期间 S* 设备仍旧上报这些重复数据会记到sos_alert表里的一个字段用于后续判断误报率。如果平台要求每次呼救都生成轨迹可以再单独维护 append-only 的原始事件表但不要用同一张表同时承接防抖判断和事件归档。4.3 家属通知要等待所有渠道返回CompletableFuture 控制超时与失败呼救确认后系统需要同时发短信给家属、推送站内信给管理员、可能还要调第三方电话通知。这个场景对应 Java 八股里常问的「多个线程等待都完成后汇总」实现时用好CompletableFuturepublic void notifyFamilyAfterSos(SosAlert alert) { ExecutorService pool new ThreadPoolExecutor( 4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(50), new ThreadPoolExecutor.CallerRunsPolicy()); CompletableFutureVoid smsFuture CompletableFuture.runAsync( () - smsClient.send(alert.getFamilyPhone(), alert.getMessage()), pool); CompletableFutureVoid appFuture CompletableFuture.runAsync( () - appPushClient.send(alert.getOperatorId()), pool); try { CompletableFuture.allOf(smsFuture, appFuture).get(5, TimeUnit.SECONDS); } catch (TimeoutException e) { // 超时也要记录短信可能已发送成功需要做补偿 smsFuture.exceptionally(ex - { log.error(sms send failed: {}, ex.getMessage()); return null; }); } catch (Exception e) { Thread.currentThread().interrupt(); } finally { pool.shutdown(); } }allOf().get(5, TimeUnit.SECONDS)是关键它等待所有异步任务完成但不会一直阻塞。如果短信通道在 5 秒内没返回主流程继续向下执行不需要把家属通知的失败拖到整个呼救流程里。线程池必须自定义不能用Executors.newFixedThreadPool因为无界队列在高并发告警时会把内存撑满CallerRunsPolicy拒绝策略在队列满时让调用线程执行任务保证通知不丢失但会影响呼救接口的返回速度需要压测时观察。5. 上线前用三项检查压住Java智慧养老平台代码的稳定性5.1 一台 4C8G 服务器上的 JVM 和连接池参数平台部署初期一台 4C8G 的云主机足够支撑 300 人同时在线操作。JVM 参数怎么配是热词里的高频问题直接给一套可用的组合堆大小设置 4GB 避免操作系统内存不足垃圾回收器在 Java 17 上直接用默认的 G1 即可不必再调 CMSJAVA_OPTS-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m \ -XX:UseG1GC -XX:MaxGCPauseMillis200 \ -Xlog:gc*:/data/logs/gc.log:time,uptime,level,tags-Xms4g和-Xmx4g保持一致避免运行期堆扩容触发 Full GC。G1 的MaxGCPauseMillis设置到 200 毫秒就够了设太短会导致 G1 频繁调整年轻代大小反而影响吞吐。MySQL 连接池配合 HikariCPmaximum-pool-size设为 20 足够一个 4C8G 实例上连接数过高只会增加上下文切换开销。5.2 慢SQL排查先看这张表再用 Arthas热修现场问题后台上线后最容易出现的卡顿都集中在工单列表和健康数据查询。先用 MySQL 自带的慢查询日志定位具体语句再针对执行计划里 type 为 ALL 的字段补索引SHOW VARIABLES LIKE slow_query_log%; SHOW GLOBAL STATUS LIKE Slow_queries; EXPLAIN SELECT * FROM service_order WHERE elderly_id 10086 AND status 1 ORDER BY created_at DESC LIMIT 20;EXPLAIN 返回结果里key为 NULL 时说明这条 SQL 没走任何索引考虑建(elderly_id, status, created_at)的联合索引。线上环境如果某个接口逻辑出现问题时用 Arthas 的trace命令跟踪方法调用耗时比反复加日志再发布高效得多以下是常用的排查命令java -jar arthas-boot.jar # 选择目标 Java 进程后在 Arthas 命令行执行 watch com.demo.order.service.ServiceOrderService dispatchOrder {params, returnObj} -x 2 trace com.demo.order.service.ServiceOrderService dispatchOrder #cost 200watch查看入参和返回值trace把所有子调用耗时打印出来#cost 200只显示超过 200 毫秒的调用适合在生产环境低流量时临时开启。注意这些命令本身有性能开销排查完要立刻stop退出不能长时间挂着。5.3 用 wrk 压测派单接口验证吞吐和防重逻辑压测目标是确认派单接口在 100 并发下不报错并且同一个工单不会被重复派发。wrk 是 Linux 上常用的压测工具一条命令就能看透接口表现wrk -t8 -c100 -d30s -s post.lua http://127.0.0.1:8080/api/order/dispatchpost.lua 里用wrk.request()构造 POST 请求把固定 orderId 放进 body。观察两个核心指标Requests/sec 是否达到预期以及非 200 响应比例。由于业务里同时有 Redis 锁和casDispatch的数据库条件更新兜底即使压测请求重复轰炸同一个工单失败率也应收敛到 0。压测时注意观察Redis connected clients和 MySQL 连接池使用率连接数打满通常是连接池配置过小的信号。整个平台上线前按这三项检查走一遍Java智慧养老平台代码的核心链路才算站得住。本文还有配套的精品资源点击获取
简介一套基于SpringBoot的智慧养老平台完整Java源码面向计算机、电子信息工程等专业学习者适合作为毕业设计、课程设计及期末大作业。系统采用B/S架构与MVC模式整合SpringBoot、Mybatis、Ajax、Vue等技术栈覆盖前端交互、后端服务与数据库设计可在Windows/Mac环境下配合JDK1.8、Mysql5.7、Maven3.6快速运行。压缩包共包含950个文件总体积17.83MB以Java源文件195个、Vue组件65个、JavaScript脚本164个、HTML页面69个及CSS样式53个为主并附带数据库脚本、配置文件与启动脚本目录划分明确便于学习和二次开发。已有335人学习下载所有源码经过严格测试可直接部署使用。这套代码能帮助读者快速理解SpringBoot实际项目的完整结构掌握前后端分离开发与养老服务业务逻辑的实现思路是提升工程实践能力的实用参考。1. Java智慧养老平台代码的核心是三条数据闭环不是一个后台管理系统一位养老机构的负责人在项目启动会上说平台要能看大屏、能看监控、能派单、家属能收到推送。听起来是标准的管理系统可一旦设备数据接入问题立刻就变了老人离床报警和SOS按钮可能一秒内上报多次护工抢单并发来了家属通知要等所有渠道都发送完再返回。Java智慧养老平台代码真正的复杂度不在增删改查而在「老人轨迹、服务工单、健康时序」这三条闭环数据如何被正确建模和处理。如果只把平台当作按角色分菜单的CRUD大概率会在联调阶段被真实的时序数据和高频上报打穿。这篇博客不贴完整源码而是把做这个标题最常见的落地路径讲清楚从ER设计、工单状态机到设备上报的防抖和并发通知再落到部署和压测参数。适合正在设计或维护养老类平台后端的Java工程师也适合团队里负责技术选型的人用来校对方案的边界。2. Java智慧养老平台代码的选型与ER设计先定表再写逻辑2.1 单体优先Spring Boot 3 MySQL 8 足够支撑两千张床位养老平台的并发量本质上是低频写、中频读几千名老人、几百名护工、每天几万条健康指标。作为技术负责人我一般不会为了这种体量引入微服务和消息中间件因为事务的复杂度远大于流量的复杂度。一个工单从创建到结算涉及订单、护工、回访、结算四个表用单体里的本地事务和数据库锁就能解决拆成微服务反而要处理分布式事务和最终一致性是给自己挖坑。建议技术栈固定为 Java 17、Spring Boot 3.x、MyBatis-Plus、MySQL 8、Redis 7。前端用 Vue3 或其他管理端框架都行和本标题关系不大不在这里展开。依赖坐标用一个最小骨架parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-spring-boot3-starter/artifactId version3.5.7/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency /dependenciesMyBatis-Plus 在 Java 智慧养老平台代码里主要价值是单表 CRUD 不用写 SQL工单查询这种多条件场景仍需要手写 XML。Redis 的用途是防抖、计数和分布式锁不是为了缓存热数据健康数据本身更适合查 MySQL 的分表。选型时把这些定位说清楚后面写代码就不会纠结技术栈是否够强。2.2 六张核心表把老人、护工、服务单、健康指标分开建模设计数据库时最容易犯的错是给平台建一张巨大的「用户表」把老人、家属、护工、管理员全塞进去。正确做法是把组织身份和业务数据分开老人是档案主数据护工是服务资源家属只作为关联通知对象。下面的表结构是 Java 智慧养老平台代码里相对通用的起步形态表名业务含义关键字段elderly_member老人档案id、name、room_no、bed_no、level、statuscaregiver护工档案id、name、phone、skills、service_scopeservice_order服务工单id、elderly_id、order_no、type、status、sos_flagorder_track工单流转记录id、order_id、from_status、to_status、operator_idhealth_metric健康指标id、elderly_id、metric_type、value、collected_atsos_alert紧急呼叫事件id、elderly_id、source、alert_time、handle_time其中 service_order 是核心它把老人的服务需求和护工的执行动作串起来order_track 是工单状态机的审计日志每次状态变更都插入一条方便追溯责任。health_metric 和 sos_alert 是设备侧的写模型特点是写入量大、几乎不更新、按时间范围查询这类表在后续章节里再做按月分表处理这里先保留逻辑外键。elderly_id 处不做物理外键理由是业务上需要支持批量导入和归档物理外键在大批量写入时会拖慢性能。一致性交给应用层保障也就是在创建工单时显式校验老人和护工的存在性。这个取舍在 Java 智慧养老平台代码场景里很常见数据库只需要承担存储和索引不需要承担业务规则。2.3 用 Java 工具自动生成数据库设计文档避免文档和表结构脱节项目迭代到第二个月数据库设计文档往往就没人维护了。常见做法是用开源工具从数据库元数据自动生成 Markdown 或 HTML 文档。这里推荐 screw数据库表结构文档生成工具它支持 MySQL、PostgreSQL能直接生成包含表注释、列注释、索引信息的文档。在测试环境执行一次输出产物丢到项目 docs 目录里配合接口文档就能覆盖大部分交接场景。// 直接用 main 方法触发无需启动 Spring 容器 public class DbDocGenerator { public static void main(String[] args) { String url jdbc:mysql://localhost:3306/elderly_care?useUnicodetruecharacterEncodingutf8; Configuration config Configuration.builder() .driver(com.mysql.cj.jdbc.Driver) .url(url) .username(root) .password(root) .build(); new DocumentGenerate(config, new ExecutePropel( ProcessConfig.builder() .designatedTableName(Arrays.asList(elderly_member, service_order)) .build() ), new MarkdownBuilder()).execute(); } }这段代码里的designatedTableName参数用来指定要导出的表不传则导出全部表。用 MarkdownBuilder 生成的文档适合放 Git 仓库评审如果在交付时要给客户看换成 HtmlBuilder 会更美观。关键点是把这个工具接进 CI 流程或至少放进项目根目录每次表结构变更顺手跑一次才能避免文档过期。3. 工单闭环是Java智慧养老平台代码的核心业务状态机和动态SQL要一起设计3.1 用枚举和事件驱动实现工单状态流转别用 if else 散落一地工单是这个平台里业务规则最密集的地方待派单、已派单、服务中、待回访、已完成、已取消。每个状态能做什么操作、谁能操作、状态怎么流转必须收敛到一处否则上线三个月后会变成维护灾难。用枚举实现状态机把当前状态、目标状态和动作绑定在事务方法里是常见的可靠做法public enum OrderStatus { PENDING_ASSIGN(0, 待派单), ASSIGNED(1, 已派单), SERVING(2, 服务中), PENDING_REVIEW(3, 待回访), COMPLETED(4, 已完成), CANCELED(5, 已取消); private final int code; private final String desc; public boolean canTransferTo(OrderStatus target) { // 定义允许的流转路径防住非法跳转 return switch (this) { case PENDING_ASSIGN - target ASSIGNED || target CANCELED; case ASSIGNED - target SERVING || target CANCELED; case SERVING - target PENDING_REVIEW || target CANCELED; case PENDING_REVIEW - target COMPLETED; default - false; }; } }这种写法把「谁能干」的校验放在 Service 层调用canTransferTo职责清晰且方便写单元测试。switch表达式中没有 case 的状态一律不接收流转包括已完成状态不允许再回退。八股文里常考的状态模式在这里的真正意义不是套设计模式而是把规则集中让新同学改需求时不用满项目找if。3.2 派单接口的事务与防重Transactional 要和分布式锁配合派单是高频操作护工在 App 抢单时多个请求可能同时命中同一个工单。单纯用数据库乐观锁可以防超卖但 Java 智慧养老平台代码里还可能涉及调第三方短信和生成派单记录这些动作不适合只靠UPDATE count count - 1去约束。推荐组合方案Redis 分布式锁控制并发数据库状态字段做兜底事务包裹业务写操作Transactional(rollbackFor Exception.class) public boolean dispatchOrder(Long orderId, Long caregiverId) { String lockKey lock:order: orderId; boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (!locked) { throw new BizException(工单正在处理中请勿重复操作); } try { // 数据库兜底必须是待派单状态才允许派单 int updated orderMapper.casDispatch(orderId, caregiverId); if (updated 0) { throw new BizException(工单状态已变化派单失败); } orderTrackMapper.insert(new OrderTrack(orderId, OrderStatus.PENDING_ASSIGN, OrderStatus.ASSIGNED, caregiverId)); return true; } finally { stringRedisTemplate.delete(lockKey); } }setIfAbsent是加锁的原子操作设置 10 秒过期防止锁未释放导致死锁。这里有个细节业务执行时间超过锁过期时间时 A 线程的锁会被 B 线程覆盖所以锁过期时间要远大于业务耗时。casDispatch是自定义 SQL核心是UPDATE service_order SET status1 WHERE id? AND status0影响行数为 0 时说明并发下状态已被其他请求更新这种写法即使 Redis 锁失效数据库条件更新也会拦截重复派单。3.3 Java对MySQL的搜索语句动态SQL处理多条件筛选平台管理后台的工单查询往往要同时支持老人姓名、护工姓名、时间范围、状态多个筛选条件用 Java 的 if 拼 SQL 很容易造成 SQL 注入或语法错误。标准做法是 MyBatis XML 里的动态标签把条件判断交给框架处理select idsearchOrders resultTypecom.demo.order.vo.OrderVO SELECT o.id, o.order_no, e.name AS elderly_name, c.name AS caregiver_name, o.status, o.created_at FROM service_order o LEFT JOIN elderly_member e ON o.elderly_id e.id LEFT JOIN caregiver c ON o.caregiver_id c.id where if testparam.status ! null AND o.status #{param.status} /if if testparam.elderlyName ! null and param.elderlyName ! AND e.name LIKE CONCAT(%, #{param.elderlyName}, %) /if if testparam.startTime ! null AND o.created_at gt; #{param.startTime} /if if testparam.endTime ! null AND o.created_at lt; #{param.endTime} /if /where ORDER BY o.created_at DESC LIMIT #{param.offset}, #{param.pageSize} /selectwhere标签会自动去掉第一个条件前多余的 AND不需要在业务代码里手动处理。LIKE 查询的CONCAT拼接能避免#{param.elderlyName}直接拼进字符串带来的注入风险。pageSize 建议限制最大值 100防止有人调LIMIT 999999把数据库拖垮。查询返回的 VO 不直接映射实体因为需要关联老人和护工的姓名字段。4. 健康设备上报与SOS呼救的并发处理Redisincrement的坑要提前排4.1 健康指标按月分表MyBatis-Plus 动态表名实现health_metric 表每天写入量取决于设备接入量一张床的智能床垫每 5 分钟上报一条体动和心率数据2000 张床一天就是约 60 万条。单表超过几百万行后按时间范围查询会明显变慢所以要在设计初期就按月分表表名类似health_metric_202506。用 MyBatis-Plus 的DynamicTableNameInnerInterceptor可以按当前月份自动路由不需要在业务代码里写死表名Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); DynamicTableNameInnerInterceptor dynamic new DynamicTableNameInnerInterceptor(); dynamic.setTableNameHandler((sql, tableName) - { if (health_metric.equals(tableName)) { return tableName _ LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMM)); } return tableName; }); interceptor.addInnerInterceptor(dynamic); return interceptor; } }这里的拦截器会在执行 SQL 前把表名替换为带后缀的物理表。需要注意这个处理器是应用级全局的对于需要跨月查询报表的场景要再手写 SQL 查多张表做 UNION ALL。分表后建表语句里的索引也要跟着调整推荐联合索引(elderly_id, collected_at)按老人查询时间范围的频率远高于跨所有老人查询。设备插入采用批量写入优化MyBatis-Plus 的saveBatch默认分批提交建议每批 500 条过高会导致单条 SQL 超过 MySQL 的max_allowed_packet。写入失败时不要整批重试先按设备 ID 分组找出失败的数据再补写避免重复消费时把完整批次再次提交。4.2 用 Redis 做SOS防抖和计数increment的类型坑要处理SOS 呼救按钮一旦按下设备往往会连续上报多次如果每次都触发一次工单创建和家属短信后果是灾难性的。常规方案是给同一老人设置一个 10 秒的防抖标记标记存在时直接丢弃同时用计数器记录上报次数作为冗余追踪信息public boolean tryAcquireSos(Long elderlyId) { String dedupKey sos:dedup: elderlyId; Boolean success stringRedisTemplate.opsForValue() .setIfAbsent(dedupKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(success)) { // 首次上报计数归 1 stringRedisTemplate.opsForValue().set(sos:cnt: elderlyId, 1); return true; } // 10 秒内重复上报计数加一 try { stringRedisTemplate.opsForValue() .increment(sos:cnt: elderlyId); } catch (Exception ex) { // 计数失败只记录日志不影响防抖主流程 log.warn(increment sos count failed: {}, ex.getMessage()); } return false; }这里必须用stringRedisTemplate而不是默认的redisTemplate否则很容易踩到increment()报错的坑使用 JDK 序列化器时存进去的字符串读到的是 byte[]increment()执行时报ClassCastException或提示value is not an integer or out of range。用StringRedisTemplatekey 和 value 都是字符串Redis 服务端会把字符串当整数处理避免序列化器带来的类型问题。防抖期间 S* 设备仍旧上报这些重复数据会记到sos_alert表里的一个字段用于后续判断误报率。如果平台要求每次呼救都生成轨迹可以再单独维护 append-only 的原始事件表但不要用同一张表同时承接防抖判断和事件归档。4.3 家属通知要等待所有渠道返回CompletableFuture 控制超时与失败呼救确认后系统需要同时发短信给家属、推送站内信给管理员、可能还要调第三方电话通知。这个场景对应 Java 八股里常问的「多个线程等待都完成后汇总」实现时用好CompletableFuturepublic void notifyFamilyAfterSos(SosAlert alert) { ExecutorService pool new ThreadPoolExecutor( 4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(50), new ThreadPoolExecutor.CallerRunsPolicy()); CompletableFutureVoid smsFuture CompletableFuture.runAsync( () - smsClient.send(alert.getFamilyPhone(), alert.getMessage()), pool); CompletableFutureVoid appFuture CompletableFuture.runAsync( () - appPushClient.send(alert.getOperatorId()), pool); try { CompletableFuture.allOf(smsFuture, appFuture).get(5, TimeUnit.SECONDS); } catch (TimeoutException e) { // 超时也要记录短信可能已发送成功需要做补偿 smsFuture.exceptionally(ex - { log.error(sms send failed: {}, ex.getMessage()); return null; }); } catch (Exception e) { Thread.currentThread().interrupt(); } finally { pool.shutdown(); } }allOf().get(5, TimeUnit.SECONDS)是关键它等待所有异步任务完成但不会一直阻塞。如果短信通道在 5 秒内没返回主流程继续向下执行不需要把家属通知的失败拖到整个呼救流程里。线程池必须自定义不能用Executors.newFixedThreadPool因为无界队列在高并发告警时会把内存撑满CallerRunsPolicy拒绝策略在队列满时让调用线程执行任务保证通知不丢失但会影响呼救接口的返回速度需要压测时观察。5. 上线前用三项检查压住Java智慧养老平台代码的稳定性5.1 一台 4C8G 服务器上的 JVM 和连接池参数平台部署初期一台 4C8G 的云主机足够支撑 300 人同时在线操作。JVM 参数怎么配是热词里的高频问题直接给一套可用的组合堆大小设置 4GB 避免操作系统内存不足垃圾回收器在 Java 17 上直接用默认的 G1 即可不必再调 CMSJAVA_OPTS-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m \ -XX:UseG1GC -XX:MaxGCPauseMillis200 \ -Xlog:gc*:/data/logs/gc.log:time,uptime,level,tags-Xms4g和-Xmx4g保持一致避免运行期堆扩容触发 Full GC。G1 的MaxGCPauseMillis设置到 200 毫秒就够了设太短会导致 G1 频繁调整年轻代大小反而影响吞吐。MySQL 连接池配合 HikariCPmaximum-pool-size设为 20 足够一个 4C8G 实例上连接数过高只会增加上下文切换开销。5.2 慢SQL排查先看这张表再用 Arthas热修现场问题后台上线后最容易出现的卡顿都集中在工单列表和健康数据查询。先用 MySQL 自带的慢查询日志定位具体语句再针对执行计划里 type 为 ALL 的字段补索引SHOW VARIABLES LIKE slow_query_log%; SHOW GLOBAL STATUS LIKE Slow_queries; EXPLAIN SELECT * FROM service_order WHERE elderly_id 10086 AND status 1 ORDER BY created_at DESC LIMIT 20;EXPLAIN 返回结果里key为 NULL 时说明这条 SQL 没走任何索引考虑建(elderly_id, status, created_at)的联合索引。线上环境如果某个接口逻辑出现问题时用 Arthas 的trace命令跟踪方法调用耗时比反复加日志再发布高效得多以下是常用的排查命令java -jar arthas-boot.jar # 选择目标 Java 进程后在 Arthas 命令行执行 watch com.demo.order.service.ServiceOrderService dispatchOrder {params, returnObj} -x 2 trace com.demo.order.service.ServiceOrderService dispatchOrder #cost 200watch查看入参和返回值trace把所有子调用耗时打印出来#cost 200只显示超过 200 毫秒的调用适合在生产环境低流量时临时开启。注意这些命令本身有性能开销排查完要立刻stop退出不能长时间挂着。5.3 用 wrk 压测派单接口验证吞吐和防重逻辑压测目标是确认派单接口在 100 并发下不报错并且同一个工单不会被重复派发。wrk 是 Linux 上常用的压测工具一条命令就能看透接口表现wrk -t8 -c100 -d30s -s post.lua http://127.0.0.1:8080/api/order/dispatchpost.lua 里用wrk.request()构造 POST 请求把固定 orderId 放进 body。观察两个核心指标Requests/sec 是否达到预期以及非 200 响应比例。由于业务里同时有 Redis 锁和casDispatch的数据库条件更新兜底即使压测请求重复轰炸同一个工单失败率也应收敛到 0。压测时注意观察Redis connected clients和 MySQL 连接池使用率连接数打满通常是连接池配置过小的信号。整个平台上线前按这三项检查走一遍Java智慧养老平台代码的核心链路才算站得住。本文还有配套的精品资源点击获取
