Java案例统计扑救次数：门将谁更忙？
目录导读
- 引言：从足球数据到Java实战
- 需求分析：扑救次数统计的核心逻辑
- 数据建模：设计门将与扑救事件的数据结构
- Java实现：统计每位门将的扑救次数
- 进阶分析：如何判断“谁更忙”
- 常见问题问答（FAQ）
- 总结与扩展建议
从足球数据到Java实战
足球比赛中，门将的扑救次数往往被用来衡量其忙碌程度与防守贡献，假设我们手头有一份比赛事件日志，记录了大量射门与扑救信息，如何用Java快速统计每位门将的扑救次数，并判断“谁更忙”？这不仅是一个贴近实际的编程案例，也是练习集合框架、Stream API与面向对象建模的好素材，本文将从需求拆解出发，给出完整可运行的Java方案,并对统计口径与扩展方向做详细说明。
需求分析：扑救次数统计的核心逻辑
统计扑救次数，本质是对“扑救事件”按门将进行分组计数，需要明确三点：第一，数据来源是比赛事件列表，每条事件包含门将标识、事件类型（射门、扑救、进球等）；第二，只有事件类型为“扑救”的记录才计入统计；第三，统计结果需要按扑救次数降序排列，便于快速识别最忙碌的门将，若存在同一门将多次出场或转会情况，应以门将唯一ID为准，而不是姓名,避免重名导致统计错误。
数据建模：设计门将与扑救事件的数据结构
建议设计两个类：Goalkeeper包含id与name；MatchEvent包含goalkeeperId、eventType与minute，事件类型可用枚举EventType表示，包含SHOT、SAVE、GOAL等，这样既保证类型安全，又便于后续扩展，实际项目中，事件数据可能来自数据库或CSV文件，本文用内存列表模拟,重点展示统计逻辑。
Java实现：统计每位门将的扑救次数
核心代码如下（示意）：
Map<String, Long> saveCount = events.stream()
.filter(e -> e.getEventType() == EventType.SAVE)
.collect(Collectors.groupingBy(
MatchEvent::getGoalkeeperId,
Collectors.counting()));
随后将结果映射为门将姓名并排序：
List<Map.Entry<String, Long>> ranked = saveCount.entrySet().stream()
.sorted(Map.Entry.<String, Long>comparingByValue().reversed())
.collect(Collectors.toList());
若需要输出“门将姓名 + 扑救次数”，可先建立id -> name的映射表，再逐条拼接，整体代码简洁，充分利用了Stream的过滤、分组与排序能力,适合处理数千至数万条事件记录。
进阶分析：如何判断“谁更忙”
仅看扑救次数并不全面，更合理的“忙碌度”可综合三个指标：扑救次数、单位时间扑救频率（扑救次数除以出场分钟数）、以及面对射门总数中的扑救占比，例如某门将扑救10次但出场90分钟，另一门将扑救8次但只出场60分钟，后者单位时间更忙，实现上可在统计扑救次数的同时，累加每位门将的出场时间，再计算频率并排序，这样得出的结论更贴近“谁更忙”的真实含义。
常见问题问答（FAQ）
问：统计时是否应排除点球大战的扑救？ 答：取决于业务口径，若只统计常规时间，可在过滤条件中增加比赛阶段字段；若统计全部正式比赛，则应保留,建议在数据模型中显式记录阶段信息。
问：门将姓名重复怎么办？ 答：必须使用唯一ID作为分组键，姓名仅用于展示,这是数据统计中最容易被忽视却最关键的一点。
问：数据量很大时Stream性能如何？ 答：对于百万级以内的事件记录，Stream分组计数性能足够；若数据量更大，可考虑并行流或先按门将ID预聚合,再合并结果。
问：如何扩展到统计扑救成功率？ 答：在事件中区分“面对射门”与“扑救成功”，分别计数后相除即可,注意分母为零的保护。
总结与扩展建议
本文以“统计扑救次数、判断门将谁更忙”为例，完整演示了Java中基于Stream的分组计数与排序方法，并讨论了统计口径、数据建模与进阶指标，实际应用中，建议将统计逻辑封装为独立服务类，配合单元测试验证边界情况（如无扑救记录、门将ID缺失等），若需持久化结果，可将排序后的列表写入数据库或导出为报表，为教练团队提供数据支持，掌握这一模式后，类似的“按维度分组计数并排序”需求都可以快速复用。
