正如其他人指出的那样,将已排序的条目流转储到常规HashMap中将无济于事……LinkedHashMap是合乎逻辑的选择.
但是,上述方法的替代方法是充分利用Stream Collectors API.
收集器具有toMap方法,可让您提供Map的替代实现.因此,您可以像下面这样要求LinkedHashMap而不是HashMap:
unsortedMap.entrySet()
.stream()
.sorted(Map.Entry.comparingByKey())
.collect(Collectors.toMap(
Map.Entry::getKey,
Map.Entry::getValue,
(v1, v2) -> v1, // you will never merge though ask keys are unique.
LinkedHashMap::new
));
在使用TreeMap与LinkedHashMap之间…构造的复杂性可能类似于O(n log n)…显然,如果您打算继续向其中添加更多元素,则TreeMap解决方案是一种更好的方法.在这种情况下,我想您应该从TreeMap开始. LinkedHashMap选项的优势在于,在链接的或原始未排序的地图上查找将为O(1),而由于TreeMap的查找类似于O(log n),因此如果需要保留未排序的地图以进行有效查找,则如果您构建LinkedHashMap,则可以扔掉原始的未排序地图(从而节省一些内存).
为了使LinkedHashMap的工作效率更高,您应该在构造时提供所需大小的良好估算器,这样就无需动态调整大小,因此,您可以说()->代替LinkedHashMap :: new.新的LinkedHashMap<>(unsortedMap.size()).
我认为TreeMap的使用更加简洁…因为可以使代码更小,因此,除非存在使用未排序和排序的链接映射方法可以解决的实际性能问题,否则我将使用Tree.