每当有人使用双大括号初始化时，就会有一只小猫被杀死。

除了语法相当不寻常且不是真正的惯用(当然，品味是有争议的)之外，您还不必要地在应用程序中创建了两个重大问题，我最近在博客中对此进行了更详细的讨论。

1. 你创建了太多的匿名类

每次使用双大括号初始化都会创建一个新类。例如这个例子:

Map source = new HashMap(){{
    put("firstName", "John");
    put("lastName", "Smith");
    put("organizations", new HashMap(){{
        put("0", new HashMap(){{
            put("id", "1234");
        }});
        put("abc", new HashMap(){{
            put("id", "5678");
        }});
    }});
}};

．.． 将产生这些类:

Test$1$1$1.class
Test$1$1$2.class
Test$1$1.class
Test$1.class
Test.class

这对您的类加载器来说是相当大的开销——毫无意义!当然，如果你只做一次，就不会花费太多初始化时间。但是如果你在整个企业应用程序中做了20000次这样的事情……那么多内存只是为了一点“语法糖”?

2. 您可能会造成内存泄漏!

如果您使用上述代码并从一个方法返回该映射，那么该方法的调用者可能会毫无疑问地持有无法被垃圾收集的非常重的资源。考虑下面的例子:

public class ReallyHeavyObject {

    // Just to illustrate...
    private int[] tonsOfValues;
    private Resource[] tonsOfResources;

    // This method almost does nothing
    public Map quickHarmlessMethod() {
        Map source = new HashMap(){{
            put("firstName", "John");
            put("lastName", "Smith");
            put("organizations", new HashMap(){{
                put("0", new HashMap(){{
                    put("id", "1234");
                }});
                put("abc", new HashMap(){{
                    put("id", "5678");
                }});
            }});
        }};

        return source;
    }
}

返回的Map现在将包含对ReallyHeavyObject的封装实例的引用。你可能不想冒这个险:

图片来自http://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/

3.你可以假装Java有地图字面量

为了回答你的实际问题，人们一直在使用这种语法来假装Java有类似map字面量的东西，类似于现有的数组字面量:

String[] array = { "John", "Doe" };
Map map = new HashMap() {{ put("John", "Doe"); }};

有些人可能会觉得这在语法上很刺激。

双大括号初始化是一种不必要的攻击，可能会导致内存泄漏和其他问题

没有合理的理由使用这种“伎俩”。Guava提供了很好的不可变集合，包括静态工厂和构建器，允许您在以干净、可读和安全的语法声明的地方填充集合。

问题中的例子是:

Set<String> flavors = ImmutableSet.of(
    "vanilla", "strawberry", "chocolate", "butter pecan");

这不仅更短，更容易阅读，而且避免了其他答案中描述的双括号模式的许多问题。当然，它的性能类似于直接构造的HashMap，但它很危险且容易出错，而且还有更好的选择。

任何时候，当你发现自己在考虑双括号初始化时，你都应该重新检查你的api或引入新的api来正确地解决这个问题，而不是利用语法技巧。

Error-Prone现在标记此反模式。

容易泄漏

我决定插话了。对性能的影响包括:磁盘操作+解压缩(针对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"));

执行以下测试类:

public class Test {
  public void test() {
    Set<String> flavors = new HashSet<String>() {{
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
    }};
  }
}

然后反编译类文件，我看到:

public class Test {
  public void test() {
    java.util.Set flavors = new HashSet() {

      final Test this$0;

      {
        this$0 = Test.this;
        super();
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
      }
    };
  }
}

在我看来，这并不是非常低效。如果我担心这样的东西的性能，我会分析它。上面的代码回答了你的问题#2:你在内部类的隐式构造函数(和实例初始化式)中，所以“this”指的是这个内部类。

是的，这个语法是模糊的，但是注释可以阐明模糊的语法用法。为了澄清语法，大多数人都熟悉静态初始化块(JLS 8.7 static Initializers):

public class Sample1 {
    private static final String someVar;
    static {
        String temp = null;
        ..... // block of code setting temp
        someVar = temp;
    }
}

您还可以使用类似的语法(没有“static”这个词)来使用构造函数(JLS 8.6实例初始化器)，尽管我从未在生产代码中看到过这种用法。这一点很少为人所知。

public class Sample2 {
    private final String someVar;

    // This is an instance initializer
    {
        String temp = null;
        ..... // block of code setting temp
        someVar = temp;
    }
}

如果没有默认构造函数，则编译器将{和}之间的代码块转换为构造函数。考虑到这一点，解开双括号代码:

public void test() {
  Set<String> flavors = new HashSet<String>() {
      {
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
      }
  };
}

最里面的大括号之间的代码块被编译器转换为构造函数。最外面的花括号分隔了匿名内部类。这是使一切都非匿名的最后一步:

public void test() {
  Set<String> flavors = new MyHashSet();
}

class MyHashSet extends HashSet<String>() {
    public MyHashSet() {
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
    }
}

对于初始化的目的，我认为没有任何开销(或者小到可以忽略不计)。但是，每次使用flavor都不会违背HashSet，而是违背MyHashSet。这可能有一个很小的开销(很可能可以忽略不计)。但是，在我担心之前，我会先分析一下。

同样，对于您的问题#2，上面的代码在逻辑上和显式地等价于双大括号初始化，并且它使“this”指的地方很明显:指向扩展HashSet的内部类。

如果您对实例初始化器的详细信息有疑问，请查看JLS文档中的详细信息。

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

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

代码如下: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.

让我知道你的想法:)