咱们一步步拆解你遇到的两个核心问题，先从Slot Sharing失效和槽位占用异常说起：

一、Slot Sharing未生效&槽位去向疑问 #

你提到设置了槽共享组但三个有状态算子仍独立调度，且总槽位320但GUI显示可用为0，主要原因可能有这几点：

1. 有状态算子的内存限制是核心障碍 #

你的三个算子都是用RocksDB的有状态算子，这类算子对内存（尤其是堆外内存）需求很高——RocksDB的写缓冲区、块缓存、状态快照都要占用大量内存。Flink的Slot是按内存配额隔离的，如果每个Slot的内存配置（taskmanager.memory.task.heap.size + taskmanager.memory.task.off-heap.size + taskmanager.memory.managed.size）不足以容纳两个有状态算子的子任务，Flink会拒绝将它们放在同一个Slot里，避免OOM。这时候Slot Sharing的配置相当于无效，每个子任务只能独占一个Slot。

你可以检查下每个Slot的内存配额：比如TaskManager总内存如果是16G，分16个Slot的话，每个Slot只有1G左右的内存，要塞两个RocksDB算子的子任务肯定不够。

2. 算子间的Shuffle连接限制了Slot共享 #

如果三个算子之间是通过keyBy这类Shuffle连接的（你提到数据用哈希分区），上下游算子的子任务是一对多/多对一的关系，不是OneToOne的直连。Flink的Slot Sharing虽然允许不同算子子任务共享Slot，但Shuffle连接的情况下，调度器会优先考虑数据局部性（减少跨节点网络传输），不会强制把上下游子任务塞进同一个Slot，这也会导致Slot Sharing没达到预期效果。

3. 剩余槽位的去向：被作业预留但未使用 #

你启动了20个16-slot的TaskManager（总320），作业用了275个Slot，但GUI显示可用为0——这是因为这些剩余的45个Slot属于分配给你这个作业的TaskManager，Flink的资源管理器会为作业独占这些TaskManager的所有Slot，即使部分Slot没被使用，也不会释放给其他作业。所以GUI里的“可用槽位”是指全局未被分配的槽位，而你的作业已经占了所有分配的TaskManager，所以显示为0。

另外，调度器的局部性偏好也可能导致每个TaskManager的Slot被部分占用：比如275个并行子任务分配到20个TaskManager，有的TaskManager跑13个，有的跑14个，剩下的2-3个Slot就在这些TaskManager里，但属于你的作业，不会被标记为“可用”。

二、负载不均的原因与解决办法 #

你说数据哈希分区但部分算子过载，这不一定是Flink故意避免均匀分配，大概率是以下原因：

1. 数据倾斜是最常见的原因 #

哈希分区的均匀性依赖key的分布均匀性，如果你的数据里存在热点key（比如某个key的流量是其他key的几十倍），对应的子任务必然会过载。这时候你需要排查数据本身的key分布，比如用Flink的Metrics查看每个子任务的处理量。

2. 调度局部性导致的硬件/资源差异 #

Flink的调度器会优先将子任务调度到有本地状态的节点（如果是恢复作业），或者靠近上游数据的节点，这可能导致某些节点的子任务遇到硬件瓶颈（比如磁盘IO慢、CPU核心少），看起来过载，但实际是硬件差异。

3. 禁用局部性调度的方法 #

如果你确定是调度局部性导致的负载不均，可以通过以下方式禁用局部性偏好，让调度器随机分配子任务：

• 提交作业时添加参数：-Djobmanager.scheduler.locality.enabled=false
• 在flink-conf.yaml中配置：jobmanager.scheduler.locality.enabled: false

但注意，禁用局部性会增加跨节点的网络传输开销，需要权衡。

另外，如果是数据倾斜导致的，你可以尝试：

• 用rebalance()算子重新均匀分区（适合无状态或状态可重新分配的场景）
• 自定义KeySelector做加盐哈希，打散热点key
• 对热点key单独处理（比如拆分热点key为多个子key）

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