到目前为止还没有指出的这种方法的一个特性是，因为创建了内部类，所以整个包含类都在其作用域中被捕获。这意味着只要你的Set是活的，它将保留一个指向包含实例的指针(这个$0)，并防止它被垃圾收集，这可能是一个问题。

这一点，以及尽管常规HashSet可以很好地工作(甚至更好)，但首先创建了一个新类的事实，使我不想使用这个构造(尽管我非常渴望语法糖)。

第二个问题:新的HashSet必须是实例初始化器中使用的“this”…有人能解释一下原理吗?我天真地以为“this”指的是初始化“flavors”的对象。

这就是内部类的工作方式。它们有自己的this，但是它们也有指向父实例的指针，所以你也可以调用包含对象的方法。在命名冲突的情况下，内部类(在您的例子中是HashSet)优先，但是您可以在类名前面加上“this”来获得外部方法。

public class Test {

    public void add(Object o) {
    }

    public Set<String> makeSet() {
        return new HashSet<String>() {
            {
              add("hello"); // HashSet
              Test.this.add("hello"); // outer instance 
            }
        };
    }
}

为了清楚地了解正在创建的匿名子类，您也可以在其中定义方法。例如重写HashSet.add()

    public Set<String> makeSet() {
        return new HashSet<String>() {
            {
              add("hello"); // not HashSet anymore ...
            }

            @Override
            boolean add(String s){

            }

        };
    }

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.

执行以下测试类:

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。 如果你需要问…更有可能的是:在你之后的人会知道这一点吗?它容易理解和解释吗?如果两个问题你都能回答“是”，那就随便用吧。

Mario Gleichman描述了如何使用Java 1.5泛型函数来模拟Scala List字面量，但遗憾的是，最终得到的是不可变列表。

他定义了这个类:

package literal;

public class collection {
    public static <T> List<T> List(T...elems){
        return Arrays.asList( elems );
    }
}

并这样使用它:

import static literal.collection.List;
import static system.io.*;

public class CollectionDemo {
    public void demoList(){
        List<String> slist = List( "a", "b", "c" );
        List<Integer> iList = List( 1, 2, 3 );
        for( String elem : List( "a", "java", "list" ) )
            System.out.println( elem );
    }
}

谷歌Collections现在是Guava的一部分，它支持类似的列表构造思想。在这次采访中，贾里德·列维说:

[…在我编写的几乎每个Java类中，使用最多的特性是减少Java代码中重复击键次数的静态方法。输入如下命令非常方便: Map<OneClassWithALongName, AnotherClassWithALongName> = Maps.newHashMap(); List<String> animals =列表。immutableList(“猫”，“狗”，“马”);

7/10/2014:如果它能像Python一样简单就好了:

动物=['猫'，'狗'，'马']

2/21/2020:在Java 11中，你现在可以说:

animals =列表。(猫，狗，马)

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

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

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"); }};

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