There's generally nothing particularly inefficient about it. It doesn't generally matter to the JVM that you've made a subclass and added a constructor to it-- that's a normal, everyday thing to do in an object-oriented language. I can think of quite contrived cases where you could cause an inefficiency by doing this (e.g. you have a repeatedly-called method that ends up taking a mixture of different classes because of this subclass, whereas ordinary the class passed in would be totally predictable-- in the latter case, the JIT compiler could make optimisations that are not feasible in the first). But really, I think the cases where it'll matter are very contrived.

我更倾向于从你是否想用大量的匿名类“把事情弄得乱七八糟”的角度来看待这个问题。作为一个粗略的指南，可以考虑使用这个习惯用法，就像使用匿名类作为事件处理程序一样。

在(2)中，您处于对象的构造函数内部，因此“this”指的是您正在构造的对象。这和其他构造函数没有什么不同。

As for (3), that really depends on who's maintaining your code, I guess. If you don't know this in advance, then a benchmark that I would suggest using is "do you see this in the source code to the JDK?" (in this case, I don't recall seeing many anonymous initialisers, and certainly not in cases where that's the only content of the anonymous class). In most moderately sized projects, I'd argue you're really going to need your programmers to understand the JDK source at some point or other, so any syntax or idiom used there is "fair game". Beyond that, I'd say, train people on that syntax if you have control of who's maintaining the code, else comment or avoid.

要创建集合，你可以使用varargs工厂方法来代替双大括号初始化:

public static Set<T> setOf(T ... elements) {
    return new HashSet<T>(Arrays.asList(elements));
}

谷歌Collections库有很多这样的方便方法，以及大量其他有用的功能。

至于这个习语的晦涩性，我一直在产品代码中遇到并使用它。我更关心的是那些被允许编写产品代码的习惯用法所迷惑的程序员。

加载许多类会在开始时增加几毫秒的时间。如果启动不是那么关键，你看看类启动后的效率，没有区别。

package vanilla.java.perfeg.doublebracket;

import java.util.*;

/**
 * @author plawrey
 */
public class DoubleBracketMain {
    public static void main(String... args) {
        final List<String> list1 = new ArrayList<String>() {
            {
                add("Hello");
                add("World");
                add("!!!");
            }
        };
        List<String> list2 = new ArrayList<String>(list1);
        Set<String> set1 = new LinkedHashSet<String>() {
            {
                addAll(list1);
            }
        };
        Set<String> set2 = new LinkedHashSet<String>();
        set2.addAll(list1);
        Map<Integer, String> map1 = new LinkedHashMap<Integer, String>() {
            {
                put(1, "one");
                put(2, "two");
                put(3, "three");
            }
        };
        Map<Integer, String> map2 = new LinkedHashMap<Integer, String>();
        map2.putAll(map1);

        for (int i = 0; i < 10; i++) {
            long dbTimes = timeComparison(list1, list1)
                    + timeComparison(set1, set1)
                    + timeComparison(map1.keySet(), map1.keySet())
                    + timeComparison(map1.values(), map1.values());
            long times = timeComparison(list2, list2)
                    + timeComparison(set2, set2)
                    + timeComparison(map2.keySet(), map2.keySet())
                    + timeComparison(map2.values(), map2.values());
            if (i > 0)
                System.out.printf("double braced collections took %,d ns and plain collections took %,d ns%n", dbTimes, times);
        }
    }

    public static long timeComparison(Collection a, Collection b) {
        long start = System.nanoTime();
        int runs = 10000000;
        for (int i = 0; i < runs; i++)
            compareCollections(a, b);
        long rate = (System.nanoTime() - start) / runs;
        return rate;
    }

    public static void compareCollections(Collection a, Collection b) {
        if (!a.equals(b) && a.hashCode() != b.hashCode() && !a.toString().equals(b.toString()))
            throw new AssertionError();
    }
}

打印

double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 34 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns

容易泄漏

我决定插话了。对性能的影响包括:磁盘操作+解压缩(针对jar)、类验证、烫发空间(针对Sun的Hotspot JVM)。 然而，最糟糕的是:它容易泄漏。你不能简单地回去。

Set<String> getFlavors(){
  return Collections.unmodifiableSet(flavors)
}

因此，如果集合转义到由不同的类加载器加载的任何其他部分，并且引用保留在那里，则整个类+类加载器树将被泄漏。为了避免这种情况，需要复制HashMap, new LinkedHashSet(new ArrayList(){{add("xxx);add("yyy");}})。不再那么可爱了。 我自己不使用成语，而是像new LinkedHashSet(Arrays.asList("xxx"，"YYY"));

我正在研究这个问题，并决定做一个比有效答案提供的更深入的测试。

代码如下:https://gist.github.com/4368924

这就是我的结论

I was surprised to find that in most of the run tests the internal initiation was actually faster (almost double in some cases). When working with large numbers the benefit seems to fade away. Interestingly, the case that creates 3 objects on the loop loses it's benefit rans out sooner than on the other cases. I am not sure why this is happening and more testing should be done to reach any conclusions. Creating concrete implementations may help to avoid the class definition to be reloaded (if that's what's happening) However, it is clear that not much overhead it observed in most cases for the single item building, even with large numbers. One set back would be the fact that each of the double brace initiations creates a new class file that adds a whole disk block to the size of our application (or about 1k when compressed). A small footprint, but if it's used in many places it could potentially have an impact. Use this 1000 times and you are potentially adding a whole MiB to you applicaiton, which may be concerning on an embedded environment. My conclusion? It can be ok to use as long as it is not abused.

让我知道你的想法:)

这将为每个成员调用add()。如果你能找到一种更有效的方法将项放入散列集中，那么就使用它。注意，内部类可能会生成垃圾，如果您对此很敏感的话。 在我看来，上下文似乎是new返回的对象，也就是HashSet。 如果你需要问…更有可能的是:在你之后的人会知道这一点吗?它容易理解和解释吗?如果两个问题你都能回答“是”，那就随便用吧。