Scala Future并发任务结合sleep运行间隔变长、耗时超预期问题

嘿，我来帮你捋捋这个问题哈！你的代码一下子提交了50个Future到默认的ExecutionContext.global线程池，但这个线程池的大小是和CPU核心数绑定的（通常是核心数×2）——比如4核CPU的话只有8个工作线程。这就导致超过线程池容量的任务会被塞进等待队列，再加上你每个任务的Thread.sleep(100*i)是递增的（第50个任务要睡5秒！），前面的长任务会一直占着线程，后面的任务排队排到天荒地老，自然间隔越来越大，总耗时远超10秒。

你要的是节流控制，也就是让任务的执行节奏可控，而不是一股脑全塞给线程池。下面给你两个针对性的解决方案：

方案1：用Semaphore控制并发数 #

如果你的需求是限制同时运行的任务数量（比如最多同时跑5个），可以用java.util.concurrent.Semaphore来做节流，这样既不会让线程池过载，也能保证任务按顺序平稳执行，不会出现间隔突然跳变的情况。

代码示例：

import java.time._
import java.util.concurrent.Semaphore
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.Future

// 限制最多同时运行5个任务
val semaphore = new Semaphore(5)

(1 to 50).map { i =>
  Future {
    semaphore.acquire() // 获取执行许可，没有的话等待
    try {
      Thread.sleep(100 * i)
      println(s"run ${i}th task at ${LocalDateTime.now}")
    } finally {
      semaphore.release() // 一定要释放许可，避免死锁
    }
  }
}

方案2：按固定速率提交任务（满足最后一个5秒后启动的需求） #

如果你明确想要第50个任务在第一个任务启动后第5秒执行，那就要精准控制任务的提交间隔——50个任务，第一个在0秒启动，第50个在5秒启动，那每个任务的提交间隔就是5000ms / 49 ≈ 102ms（或者直接按100ms间隔，第50个在4.9秒启动，几乎接近5秒的预期）。

可以用java.util.concurrent.ScheduledExecutorService来定时提交任务：

import java.time._
import java.util.concurrent.Executors
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.Future

val scheduler = Executors.newSingleThreadScheduledExecutor()
val startTime = LocalDateTime.now

(1 to 50).foreach { i =>
  // 第i个任务延迟 (i-1)*100ms 提交，保证间隔均匀
  scheduler.schedule(() => {
    Future {
      Thread.sleep(100 * i)
      println(s"run ${i}th task at ${LocalDateTime.now}, time since start: ${Duration.between(startTime, LocalDateTime.now).toMillis}ms")
    }
  }, (i-1)*100, java.util.concurrent.TimeUnit.MILLISECONDS)
}

// 所有任务提交完成后可按需关闭调度器
// scheduler.shutdown()

这个方案里，每个任务按100ms的间隔依次提交，第50个任务会在第一个任务启动后4900ms（约5秒）时开始执行，完全符合你的预期。而且因为是按间隔分批提交，线程池不会一下子被占满，任务执行的并发效率也能保证。

额外小提示 #

• 尽量避免在Future里直接用Thread.sleep，如果是模拟耗时操作，建议用scala.concurrent.blocking包裹，这样ExecutionContext会临时增加线程数，避免阻塞其他任务：

  Future {
    blocking {
      Thread.sleep(100 * i)
    }
    // ... 其他业务逻辑
  }
  

• 如果你的任务量很大，或者需要更复杂的流控、背压机制，也可以考虑用Akka Streams或者FS2这类流式处理库，它们自带成熟的节流工具。

内容的提问来源于stack exchange，提问作者WeiChing 林煒清