blocks|key|195952|text|根据我的个人经验，在API需要一组参数，但您没有提供任何东西的情况下，它是非常有用的。例如，您可能有一个如下所示的API，并且不允许空引用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|195953|public+ResultSet+executeQuery(String+query,+Map<String,+Object>+queryParameters);|code-block|syntax|javascript|195954|如果你有一个不带任何参数的查询，创建一个HashMap肯定有点浪费，这涉及到分配一个数组，而你可以像在java.util.Collections中实现的那样，只传入一个有效的常量“空映射”。|offset|length|style|CODE|195955|entityMap^0|0|0|1F|L|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

It is, in my personal experience admittedly, very useful in cases where an API requires a collection of parameters, but you have nothing to provide. For example you may have an API that looks something like this, and does not allow null references:

<pre><code>public ResultSet executeQuery(String query, Map&lt;String, Object&gt; queryParameters);
</code></pre>

If you have a query that doesn't take any parameters, it's certainly a bit wasteful to create a HashMap, which involves allocating an array, when you could just pass in the 'Empty Map' which is effectively a constant, the way it's implemented in <code>java.util.Collections</code>.

blocks|key|2826555|text|从Effective+Java中，项目#43+-+"Return+empty+arrays+or+collections,+not+null"演示了返回一个空集合，甚至可能演示了在Collections类上使用这些emptyList()、emptySet()和emptyMap()方法来获得一个空集合，该集合还具有不可变的额外好处。来自Item+#15+"Minimize+Mutability"。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|2826556|来自Collections-emptySet-Collections-emptyList-Collections|2826557|2826558|是一种编程习惯用法。这是为那些不想要空变量的人准备的。因此，在集合初始化之前，它们可以使用空集。|blockquote|2826559|2826560|2826561|注意:下面的代码只是一个示例(根据您的用例进行更改)：|2826562|private+Set+myset+=+Collections.emptySet();

void+initSet()+{
+++myset+=+new+HashSet();
}
void+deleteSet()+{
+++myset+=+Collections.emptySet();
}|code-block|syntax|javascript|2826563|这些方法有几个优点：|2826564|2826565|它们更简洁，因为您不需要显式地键入集合的泛型类型-它通常只是从方法调用的上下文中推断出来的。|ordered-list-item|2826566|它们效率更高，因为它们不需要创建新的对象；它们只是重用现有的空的和不可变的对象。这种影响通常很小，但偶尔(好吧，很少)很重要。|2826567|2826568|entityMap|0|LINK|mutability|MUTABLE|url|http://www.coderanch.com/t/536728/java/java/Collections-emptySet-Collections-emptyList-Collections^0|1|E|H|5|4O|8|P|1A|2Z|B|3B|A|3M|A|4X|L|0|2|1I|0|0|0|0|0|0|0|6|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|D]|$9|1L|A|1M|B|D]|$9|1N|A|1O|B|D]|$9|1P|A|1Q|B|D]|$9|1R|A|1S|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|1T|8|@]|E|@$9|1U|A|1V|1|1W]]|F|$]]|$1|I|3|-4|5|6|7|1X|8|@]|E|@]|F|$]]|$1|J|3|K|5|L|7|1Y|8|@]|E|@]|F|$]]|$1|M|3|-4|5|6|7|1Z|8|@]|E|@]|F|$]]|$1|N|3|-4|5|6|7|20|8|@]|E|@]|F|$]]|$1|O|3|P|5|6|7|21|8|@$9|22|A|23|B|C]]|E|@]|F|$]]|$1|Q|3|R|5|S|7|24|8|@]|E|@]|F|$T|U]]|$1|V|3|W|5|6|7|25|8|@]|E|@]|F|$]]|$1|X|3|-4|5|6|7|26|8|@]|E|@]|F|$]]|$1|Y|3|Z|5|10|7|27|8|@]|E|@]|F|$]]|$1|11|3|12|5|10|7|28|8|@]|E|@]|F|$]]|$1|13|3|-4|5|6|7|29|8|@]|E|@]|F|$]]|$1|14|3|-4|5|6|7|2A|8|@]|E|@]|F|$]]]|15|$16|$5|17|18|19|F|$1A|1B]]]]

From Effective Java, Item #43 - <code>"Return empty arrays or collections, not null"</code> demonstrates returning an empty collection and perhaps even demonstrates using these <code>emptyList()</code>, <code>emptySet()</code>, and <code>emptyMap()</code> methods on the Collections class to get an empty collection that also has the additional benefit of being immutable. From Item #15 <code>"Minimize Mutability"</code>.

From <a href="http://www.coderanch.com/t/536728/java/java/Collections-emptySet-Collections-emptyList-Collections" rel="noreferrer">Collections-emptySet-Collections-emptyList-Collections</a> 

<blockquote>
 Its a type of programming idiom. This is for people that do not want null variables. So before the set gets initialized, they can use the empty set. 
</blockquote>

Note: Below code is just an example (change it according to your use case): 

<pre><code>private Set myset = Collections.emptySet();

void initSet() {
 myset = new HashSet();
}
void deleteSet() {
 myset = Collections.emptySet();
}
</code></pre>

These methods offer a couple of advantages:

<ol>
<li>They're more concise because you don't need to explicitly type out the generic type of the collection - it's generally just inferred from the context of the method call. </li>
<li>They're more efficient because they don't bother creating new objects; they just re-use an existing empty and immutable object. This effect is generally very minor, but it's occasionally (well, rarely) important.</li>
</ol>

blocks|key|197837|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|197838|为什么我要一个不可变的空集合？这有什么意义？|blockquote|197839|197840|197841|出于同样的原因，您可能会在某些时候使用Collections.unmodifiableMap()。您希望返回一个Map实例，该实例在用户试图修改它时抛出异常。这只是一个特例:空地图。|offset|length|style|CODE|197842|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableMap%2528java.util.Map%2529^0|0|0|0|0|J|T|J|T|0|0^^$0|@$1|2|3|-4|4|5|6|T|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|U|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|W|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|X|7|@$H|Y|I|Z|J|K]]|8|@$H|10|I|11|1|12]]|9|$]]|$1|L|3|-4|4|5|6|13|7|@]|8|@]|9|$]]]|M|$N|$4|O|P|Q|9|$R|S]]]]

<blockquote>
 Why would I want an immutable empty collection? What is the point?
</blockquote>

For the same reason you'd use <a href="http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableMap%28java.util.Map%29" rel="nofollow"><code>Collections.unmodifiableMap()</code></a> at some point. You want to return a Map instance that throws an exception if the user attempts to modify it. It's just a special case: the empty Map.

blocks|key|3039453|text|首先，你可以通过引用共享逃脱惩罚。new+HashMap()等将需要一个已分配的对象，可能还需要一些额外的元素来保存数据，但您只需要不可变的空集合(列表、集合、映射或任何其他类型)的一个副本。这使得当您调用的方法需要接受Map但不需要编辑它时，它是一个显而易见的选择。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3039454|我建议看看Josh+Bloch的Effective，它列出了不可变对象的一些非常好的属性(包括线程安全性)。|3039455|entityMap^0|H|D|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

For one, you can get away with reference sharing. A <code>new HashMap()</code> etc will require an allocated object, and possibly some extra elements to hold the data, but you only need one copy of an immutable empty collection (list, set, map, or any other such). This makes it an obvious choice when a method you're calling needs to accept a Map but does not need to edit it.

I suggest checking out Josh Bloch's Effective Java, which lists some very nice attributes of immutable objects (including thread safety).

blocks|key|195988|text|当您有一个返回immutable+collection的函数，并且在某些情况下没有要返回的数据时，它可能会很有用，因此您可以返回emptyMap()而不是返回null|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|195989|它使您代码更简单，并防止NullPointerException|195990|entityMap^0|7|K|1S|A|27|4|0|C|K|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

It can be useful when you have a function that returns an <code>immutable collection</code> and in some situation there is no data to return so instead of returning <code>null</code> you can return <code>emptyMap()</code>

It make your code easier and prevent <code>NullPointerException</code>

blocks|key|195998|text|大多数情况下，我们使用constructor来创建新的empty+map。但是，Collections+methods为使用static+method+java.util.Collections.emptyMap()创建empty+map提供了一些优势|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|195999|196000|blockquote|196001|196002|它们更简洁，因为您不需要显式地键入集合的泛型类型--它通常只是从方法call.|196003|They're的上下文中推断出来的，效率更高，因为它们不需要费心创建新对象；它们只重用现有的空的和不可变的对象。这种影响通常很小，但偶尔(好吧，很少)很重要。|unordered-list-item|196004|196005|entityMap^0|B|B|R|9|14|B|1G|7|1Q|6|1X|6|24|W|32|9|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|18|8|@]|D|@]|E|$]]|$1|G|3|-4|5|H|7|19|8|@]|D|@]|E|$]]|$1|I|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1B|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1C|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]|$1|P|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|Q|$]]

Most of the time we use a <code>constructor</code> to create a new <code>empty map</code>. But the <code>Collections</code> <code>methods</code> offer a couple of advantages to create an <code>empty map</code> using <code>static</code> <code>method</code> <code>java.util.Collections.emptyMap()</code>

<blockquote>
 <ol>
 <li>They're more concise because you don't need to explicitly type out the generic type of the collection - it's generally just inferred from
 the context of the method call.</li>
 <li>They're more efficient because they don't bother creating new objects; they just re-use an existing empty and immutable object. This
 effect is generally very minor, but it's occasionally (well, rarely)
 important.</li>
 </ol>
</blockquote>

blocks|key|200445|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|200446|为什么我要一个不可变的空集合？这有什么意义？|blockquote|200447|200448|200449|出于同样的原因，你可能想要不可变的对象。主要是因为您知道多个线程可以访问对象的同一实例，并且它们都将看到相同的值，因此您可以在晚上安全地入睡。集合中没有项仍然是一个有效值，您可能希望维护该值。|200450|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|J|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|K|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]]|I|$]]

<blockquote>
 Why would I want an immutable empty collection? What is the point?
</blockquote>

For the same reasons why you might want immutable objects. Primarily because you can sleep safe at night in the knowledge that multiple threads can access the same instance of an object and that they will all be seeing the same values. Having no items in a collection is still a valid value, which you would want to maintain.

blocks|key|198682|text|在一些情况下，您更喜欢使用不可变的映射、列表、集合或其他类型的集合。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|198683|第一个，也是可以说是最重要的用例是，每当您返回查询或计算的结果，而该结果将返回一组结果(或列表或映射)时，您应该更喜欢使用不可变数据结构。|offset|length|style|BOLD|198684|在这种情况下，我更喜欢返回它们的不可变版本，因为这更清楚地反映了计算结果集的事实不可变性-无论您稍后如何处理数据，从查询中收到的结果集都不应该改变。|198685|第二个常见用例是需要提供一个参数作为方法或服务的输入。除非您希望输入集合被服务或方法修改(这通常是一个非常糟糕的设计思想)，否则在许多情况下，传递一个不可变的集合而不是可变的集合可能是合理且安全的选择。|198686|我认为这是“按值传递”的约定。|198687|更一般地说是-当数据跨越模块或服务边界时，使用不可变的数据结构是一种明智的做法。这使得推断(不可变的)输入/输出和可变的内部状态之间的差异变得更加容易。|198688|这样做的一个非常有益的副作用是提高了模块/服务的安全性和线程安全性，并确保了关注点的更清晰分离。|198689|使用Collections.empty*()方法的另一个很好的原因是它们明显缺乏冗长。在Java7之前的时代，如果你有一个泛型集合，你必须到处散布泛型类型注释。|CODE|198690|只需比较这两个声明：|198691|Map<Foo,+Comparable<?+extends+Bar>>+fooBarMap+=+new+HashMap<Foo,+Comparable<?+extends+Bar>>();|code-block|syntax|javascript|198692|对比：|198693|Map<Foo,+Comparable<?+extends+Bar>>+fooBarMap+=+Collections.emptyMap();|198694|后者显然在可读性方面以两种重要方式赢得了胜利：|198695|198696|在第一个声明中，空映射的整个实例化被淹没在泛型类型声明的噪声中，这使得本质上微不足道的声明变得比需要的更加隐蔽。|ordered-list-item|198697|除了右侧明显缺少泛型类型注释之外，第二个版本还明确地声明映射被初始化为一个空映射。此外-知道此方法返回一个不可变的映射，现在只需搜索/fooBarMap+=/.|198698|，就可以更容易地找到fooBarMap被赋予另一个非空值的位置|198699|entityMap^0|0|0|3|0|0|0|3|0|0|0|6|0|0|2|K|0|0|0|0|0|0|0|0|1U|D|0|A|9|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1I|8|@$D|1J|E|1K|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1L|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1M|8|@$D|1N|E|1O|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1P|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1T|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1U|8|@$D|1V|E|1W|F|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1X|8|@]|9|@]|A|$]]|$1|W|3|X|5|Y|7|1Y|8|@]|9|@]|A|$Z|10]]|$1|11|3|12|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|13|3|14|5|Y|7|20|8|@]|9|@]|A|$Z|10]]|$1|15|3|16|5|6|7|21|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|18|3|19|5|1A|7|23|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|1A|7|24|8|@$D|25|E|26|F|T]]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|27|8|@$D|28|E|29|F|T]]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|2A|8|@]|9|@]|A|$]]]|1G|$]]

There are couple of cases where you would prefer using immutable maps, lists, sets or other types of collections.

First and arguably most important use case is whenever you return a result of a query or a computation that would return a set (or list or map) of results, you should prefer to use immutable data structures. 

In this case, I much prefer to return immutable versions of these as this reflects the factual immutability of a resultset of a computation much more clearly - no matter what you do with the data later, the set of results you received from your query should not change.

Second common use case is when you need to provide an argument as an input to a method or service. Unless you expect the input collection to be modified by the service or method (which is usually a really bad design idea), passing in an immutable collection instead of the mutable one might be the reasonable and safe choice in many cases. 

I think of it as "pass by value" convention.

More generally - it is a sensible practice to use an immutable data structures whenever data crosses module or service boundaries. This makes it much easier to reason about differences between (immutable) input/output and mutable internal state. 

As a very beneficial side effect of this is increased security and thread safety of your modules/services and ensures cleaner separation of concerns.

Another good reason to use <code>Collections.empty*()</code> methods is their noticeable lack of verboseness. In pre-Java7 era, if you had a generic collection, you had to sprinkle generic type annotations all over the place.

Just compare these two declarations:

<pre><code>Map&lt;Foo, Comparable&lt;? extends Bar&gt;&gt; fooBarMap = new HashMap&lt;Foo, Comparable&lt;? extends Bar&gt;&gt;();
</code></pre>

versus:

<pre><code>Map&lt;Foo, Comparable&lt;? extends Bar&gt;&gt; fooBarMap = Collections.emptyMap();
</code></pre>

The latter clearly wins hands-down on readability in two important ways:

<ol>
<li>In the first declaration, the whole instantiation of an empty map is buried in the noise of generic type declarations, making an essentially trivial declaration much more cryptic than it needs to be.</li>
<li>In addition to notable lack of generic type annotation on the right side, the second version clearly states that the map is initialized to an empty map. 
In addition - knowing that this method returns an immutable map, it is now easier for me to find where <code>fooBarMap</code> is being assigned another nonempty value just by searching for <code>/fooBarMap =/</code>.</li>
</ol>

blocks|key|2826799|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2826800|为什么我要一个不可变的空集合？这有什么意义？|blockquote|2826801|2826802|2826803|这里有两个不同的概念，当一起查看时，它们看起来很奇怪。当您分开对待这两个概念时，这会更有意义。|2826804|2826805|首先，您应该尽可能使用不可变的集合，而不是可变的集合。不变性的好处是很好的，documented+elsewhere.|unordered-list-item|offset|length|2826806|Secondly，你应该更喜欢使用一个空集合而不是使用null作为前哨。这是well+described+here。这意味着你将拥有更干净，更容易理解的代码，更少的隐藏bug的地方。|2826807|2826808|因此，当您有需要map的代码时，最好传递一个空map而不是null来表示缺少map。在大多数情况下，当您使用map时，最好使用不可变的map。这就是为什么有一个方便的函数来创建一个不可变的空map的原因。|2826809|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/214714/mutable-vs-immutable-objects/214718#214718|1|https://stackoverflow.com/a/1970001/249879^0|0|0|0|0|0|0|12|K|0|0|12|J|1|0|0|0^^$0|@$1|2|3|-4|4|5|6|12|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|13|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|14|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|15|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|16|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|17|7|@]|8|@]|9|$]]|$1|I|3|J|4|K|6|18|7|@]|8|@$L|19|M|1A|1|1B]]|9|$]]|$1|N|3|O|4|K|6|1C|7|@]|8|@$L|1D|M|1E|1|1F]]|9|$]]|$1|P|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|1H|7|@]|8|@]|9|$]]|$1|S|3|-4|4|5|6|1I|7|@]|8|@]|9|$]]]|T|$U|$4|V|W|X|9|$Y|Z]]|10|$4|V|W|X|9|$Y|11]]]]

<blockquote>
 Why would I want an immutable empty collection? What is the point?
</blockquote>

There are two different concepts here that appear strange when viewed together. It makes more sense when you treat the two concepts separately.

<ul>
<li>Firstly, you should prefer to use an immutable collection rather than a mutable one wherever possible. The benefits of immuablity are well <a href="https://stackoverflow.com/questions/214714/mutable-vs-immutable-objects/214718#214718">documented elsewhere</a>.</li>
<li>Secondly, you should prefer to use an empty collection rather than to use null as a sentinel. This is <a href="https://stackoverflow.com/a/1970001/249879">well described here</a>. It means that you will have much cleaner, easier to understand code, with fewer places for bugs to hide.</li>
</ul>

So when you have code that requires a map, it is better to pass an empty map rather than a null to indicate the absence of a map. And most of the time when you are using a map, it is better to use an immutable map. So this is why there is a convenience function to make an immutable empty map.

What are some of the situations where I can use <code>Collections.emptyMap()</code> ? The Documentation says I can use this method if I want my collection to be immutable. 

Why would I want an immutable empty collection? What is the point?

Collections.emptyMap() vs new HashMap()

数据结构

Java

我可以在哪些情况下使用Collections.emptyMap()？文档说如果我希望我的集合是不可变的，我可以使用这个方法。为什么我要一个不可变的空集合？重点是什么？

问Collections.emptyMap() vs新的HashMap()
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Collections.emptyMap() vs新的HashMap()EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Collections.emptyMap() vs新的HashMap()
EN