0

开始看 Hazelcast ( 3.4.4)。最少的配置。测试：

 case class Ticket(id:Int, name:String)

val ticketCount = 20
      val tickets:List[Ticket] = for { n <- (0 until ticketCount).toList } yield Ticket(n, s"ticket$n")

val map: IMap[Long, Ticket] = hz1.getMap[Long,Ticket]("com.foo.testmap")

tickets foreach { t =>
    println(s"submitting $t")
    Thread.sleep(10)  // some delay to submit one ticket
    map.putIfAbsent(t.id, t)
}


Thread.sleep(2000) // two seconds to make sure all is set..


var value1 = map.get(19)             // null 

var value2 = map.containsKey(19) )   // false  

val value3 = map.getAsync(19).get()   // Ticket(19,ticket19)

为什么 null，为什么false，为什么只map.getAsync(19).get()有效？

不过，这：

  val iterator = map.entrySet().iterator()      // will print all values
  while(iterator.hasNext) {
    val next = iterator.next()
    println(next)
  }

将打印所有条目。

更新：

在配置中：

<map name="com.foo.testmap">
  <in-memory-format>OBJECT</in-memory-format>
</map>
4

1 回答 1

4

当您更改为时，它按预期var value1 = map.get(19)工作var value1 = map.get(19l)

将数据存储到地图时，您使用 Long 作为键。但是，您正在使用 Integer 来取回数据。正如您在 IMap合同中看到的，相等比较使用密钥的二进制（序列化）形式，而不是密钥本身。显然，long 被序列化为与整数不同的二进制文件。

该方法getAsync()与get()它使用泛型的方法不同，我假设 Scala 编译器在幕后将密钥转换为 Long 。

它是自动装箱和 Scala 编译器魔法的结合，创造了一种看似不一致的行为。然而，当我想到它时，它并没有那么出乎意料。的行为j.u.Map完全相同。以下测试也失败了：

@Test
public void surpriseNotReally() {
    Map<Long, String> map = new HashMap<>();

    long key = 1;
    String expectedValue = "foo";
    map.put(key, expectedValue);

    String actualValue =  map.get(1);
    assertEquals(expectedValue, actualValue);
}
于 2015-08-09T11:47:20.097 回答