documentation爲scala.collection.mutable.Map
說。Map實現爲什麼要覆蓋foreach?
爲了提高效率,覆蓋方法
foreach
和size
也是好主意。
重寫size
是(可能)一個O(n)
到O(1)
改進。
但是,覆蓋foreach
的值是多少?
documentation爲scala.collection.mutable.Map
說。Map實現爲什麼要覆蓋foreach?
爲了提高效率,覆蓋方法
foreach
和size
也是好主意。
重寫size
是(可能)一個O(n)
到O(1)
改進。
但是,覆蓋foreach
的值是多少?
scala.collection.immutable.MapLike中的foreach的默認實現使用迭代器來實現foreach。該實現從IterableLike繼承。
def foreach[U](f: A => U): Unit =
iterator.foreach(f)
但是實現一個迭代器通常比實現foreach要複雜得多。迭代器必須明確地跟蹤當前位置,該位置需要狀態,並且在樹狀結構(例如,例如,什麼用於不可變的HashMaps。下面是來自當前集合庫的不可變HashMaps和HashSets的迭代器,例如TrieIterator。不完全簡單,對吧?
另一方面,foreach方法使用調用堆棧來跟蹤當前位置,因此實現起來非常簡單和高效。一個二叉樹的foreach方法就是left.foreach(f); right.foreach(F)。
因此,根據您的地圖的迭代器的複雜程度,對性能分別實現foreach可能確實是一個好主意。
我想這是因爲你正在處理一個可變的地圖。如果你對多個進程之間共享的可變集合有很多迭代,事情可能會非常錯誤。例如,如果元素被刪除但在迭代器中沒有遍歷,那麼呢? foreach
方法(從Iterator)的默認實現不使用任何種類的併發處理。
相同的註釋不會出現在不可變的版本中。
'Map'確實保證了線程安全性。一般來說,在Java/Scala中,除非另有聲明,否則事物不是線程安全的,從而不會導致同步處罰。 –
有趣的是,['immutable.Map'](http://www.scala-lang.org/api/2.10.3/index.html#scala.collection.immutable.Map)的文檔沒有這樣的建議。 –
也許他們不希望儘可能多的人來擴展immutable.Map?重寫性能的foreach對於不可變映射也是一個好主意,而HashMap顯然也是這樣。 –