Akka 2.7.0集群分片场景下内存泄漏问题求助

1. 配置分片实体的自动超时清理 #

禁用remember-entities后，Akka集群分片不会自动清理已停止Actor的分片元数据，需显式配置实体钝化与元数据清理规则：

akka.cluster.sharding {
  entity-passivation {
    timeout = 5m # 根据任务实际时长调整，确保任务完成后Actor能被钝化
  }
  cleanup-interval = 1m # 定期清理过期实体元数据的间隔
  removed-entities-retention-time = 10m # 已移除实体元数据的保留时长，到期自动清理
}

2. 任务结束后手动触发分片清理 #

在所有任务完成的钩子逻辑中，主动向分片协调器发送清理指令，批量移除已停止的分片实体：

import akka.cluster.sharding.ShardCoordinator.RemoveShard
import akka.cluster.sharding.ClusterSharding

// 获取目标实体类型的分片协调器引用
val coordinator = system.actorSelection("/system/sharding/[你的实体类型名称]/coordinator")
// 批量发送分片清理指令（可根据实际分片ID范围循环处理）
coordinator ! RemoveShard("shard-id-xxx")

3. 优化Cassandra持久化连接池配置 #

针对之前的Cassandra连接问题，调整客户端连接池参数，避免空闲连接或未释放资源占用内存：

akka.persistence.cassandra {
  session {
    connection-pool {
      max-connections = 64 # 匹配16vCPU的硬件规格，避免过多空闲连接
      idle-timeout = 10m # 空闲连接自动回收时长
    }
  }
}

4. 升级Akka至修复版本 #

你遇到的内存泄漏问题已在Akka 2.7.4及后续版本中被官方修复（对应GitHub Issue #29977），该问题源于禁用remember-entities时，分片协调器未正确清理已移除实体的追踪数据。直接升级到Akka 2.7.4或更高稳定版本可从根源解决问题。

5. GC日志辅助验证 #

在调整配置或升级前，可通过GC日志确认内存泄漏类型，验证解决方案有效性：
添加JVM参数生成GC日志：

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

分析日志中老年代内存增长趋势，确认是元数据堆积还是对象实例泄漏。

内容的提问来源于stack exchange，提问作者user3477337