Scala Actors：JRE 1.5 和 1.6 上的不同行为

Question

我的模拟使用 actor 和 Scala 2.8-Snapshot。在 Java JRE 1.5 中它运行良好 - 所有 40 个齿轮（参与者）都同时工作。使用 Java JRE 1.6 只有 3 个齿轮同时工作。我在使用和不使用 GUI 的情况下对其进行了测试：两者都给出相同的结果。

我的 GUI 模拟可以在 github 上找到： http://github.com/pmeiclx/scala_gear_simulation

也许你记得我与演员的第一个问题。解决这些问题后，我做了一个 GUI 进行模拟，并得到了这个新的“奇怪”行为。

这是没有 GUI 的代码：

package ch.clx.actorversions

import actors.Actor
import actors.Actor._
import collection.mutable.ListBuffer

case class ReceivedSpeed(gear: Gear)
case object StartSync

case class SyncGear(controller: GearController, syncSpeed: Int)

object ActorVersion {

  def main(args:Array[String]) = {
    println("[App] start with creating gears")
    val gearList = new ListBuffer[Gear]()
    for (i <- 0 until 100) {
      gearList += new Gear(i)
    }

    val gearController = new GearController(gearList)

    gearController.start()
    gearController ! StartSync
  }
}

/**
 * CONTROLLER
 */
class GearController(nGears: ListBuffer[Gear]) extends Actor {
  private var syncGears = new ListBuffer[Gear]
  private var syncSpeed = 0
  def act = {
    while(true) {
      receive {
        case StartSync => {
          println("[Controller] Send commands for syncing to gears!")
          var speeds = new ListBuffer[Int]
          nGears.foreach(e => speeds += e.speed)

          //Calc avg
          //var avgSpeed = speeds.foldLeft(0)(_ + _) / speeds.length
          //var avgSpeed = speeds.foldLeft(0) { (x, y) => x + y } / speeds.length
          syncSpeed = (0/:speeds)(_ + _) / speeds.length //Average over all gear speeds

          //TODO syncSpeed auf Median ausrichten

          println("[Controller] calculated syncSpeed: "+syncSpeed)
          nGears.foreach{e =>
                         e.start()
                         e ! SyncGear(this, syncSpeed)
          }
          println("[Controller] started all gears")
        }
        case ReceivedSpeed(gear: Gear) => {
          println("[Controller] Syncspeed received by a gear ("+gear.gearId+")")
          //println("[Controller] mailboxsize: "+self.mailboxSize)
          syncGears += gear
          if(syncGears.length == nGears.length) {
            println("[Controller] all gears are back in town!")
            System.exit(0)
          }
        }
        case _ => println("[Controller] No match :(")
      }
    }
  }
}

/**
 * GEAR
 */
class Gear(id: Int) extends Actor {

  private var mySpeed = scala.util.Random.nextInt(1000)
  private var myController: GearController = null

  def speed = mySpeed
  def gearId = id

  /* Constructor */
  println("[Gear ("+id+")] created with speed: "+mySpeed)

  def act = {
    loop {
      react {
        case SyncGear(controller: GearController, syncSpeed: Int) => {
          //println("[Gear ("+id+")] activated, try to follow controller command (form mySpeed ("+mySpeed+") to syncspeed ("+syncSpeed+")")
          myController = controller
          adjustSpeedTo(syncSpeed)
        }
      }
    }
  }

  def adjustSpeedTo(targetSpeed: Int) = {
    if(targetSpeed > mySpeed) {
      mySpeed += 1
      self ! SyncGear(myController, targetSpeed)
    }else if(targetSpeed < mySpeed) {
      mySpeed -= 1
      self ! SyncGear(myController, targetSpeed)
    } else if(targetSpeed == mySpeed) {
      callController
    }
  }

  def callController = {
    println("[Gear ("+id+")] has syncSpeed")
    myController ! ReceivedSpeed(this)
  }
}

Answer 1

简短回答：更改控制器以使用loop/react而不是while/receive

Actor库检测它正在运行的Java版本，如果它是1.6（而不是IBM的VM），它使用JSR-166y fork的捆绑版本加入线程池，因此根据Java版本，底层实现存在很大差异。

fork/join 线程池使用一种两级队列来执行任务。每个工作线程都有一个队列，并且池中有一个共享队列。源自 fork/join 线程的任务直接进入 fork/join 线程的队列，而不是通过主队列。线程之间的任务窃取用于保持线程繁忙并帮助避免饥饿。

在您的情况下，启动齿轮的所有任务最终都会出现在运行控制器的线程的队列中。因为您在该参与者中使用 while/receive，所以它永远不会释放线程，因此它永远不会直接在其队列上执行任务。其他线程一直忙于 3 个齿轮，因此它们从不尝试从运行控制器的线程窃取工作。结果是其他齿轮演员从未被处决。

在控制器中切换到循环/反应应该可以解决这个问题，因为在每个循环中，参与者都会释放线程并调度一个新任务，该任务将最终位于队列的后面，因此队列中的其他任务将被执行。

Answer 2

使用 Java JRE 1.6 只有 3 个齿轮同时工作。

您的意思是：

• 只有三个档位才能达到目标速度。当三个档位达到目标速度时，不再有任何档位取得任何进展。
• 任何时候只有三个档位取得进展。当三个档位中的一个达到目标速度时，另一个档位开始前进，直到所有档位都达到目标速度。

我猜第二个？

观察到的行为差异可能归因于 JVM 实现的差异 - JRE 1.5 和 JRE 1.6 之间存在变化。其中一些更改可以关闭，例如通过设置如下所示的标志：

-XX:ThreadPriorityPolicy=1

...但第二种行为是执行代码的完全有效的方式。这不是您所期望的，因为它违反了您所拥有的“公平”概念，但工作调度程序却没有。您可以添加某种时钟 actor，以确保最受青睐的装备比最不受青睐的 actor 接收的时间不超过（比如说）10 个“刻度”。

就很难研究 JRE 之间的差异

• 如果不了解您正在使用的 JRE 更新版本，
• 。您运行哪个操作系统。
• 您有多少个 CPU 和内核。
• 代码是否已针对 JRE 1.6 重新编译。

祝你好运！