在Java的隐藏特性中,最上面的答案提到了双大括号初始化,语法非常诱人:

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

这个习惯用法创建了一个匿名的内部类,其中只有一个实例初始化式,它“可以使用任何[…]]方法”。

主要问题:这真的像听起来那么低效吗?它的使用应该仅限于一次性的初始化吗?(当然还有炫耀!)

第二个问题:新的HashSet必须是实例初始化器中使用的“this”…有人能解释一下原理吗?

第三个问题:在产品代码中使用这个习语是否过于晦涩?

非常非常好的回答,谢谢大家。关于问题(3),人们认为语法应该清楚(尽管我建议偶尔注释一下,特别是如果您的代码将传递给可能不熟悉它的开发人员)。

对于问题(1),生成的代码应该快速运行。额外的.class文件确实会导致jar文件混乱,并略微减慢程序启动速度(感谢@coobird测量)。@Thilo指出,垃圾收集可能会受到影响,在某些情况下,额外加载类的内存成本可能是一个因素。

问题(2)对我来说是最有趣的。如果我理解了答案,DBI中发生的事情是匿名内部类扩展了new操作符所构造的对象的类,因此有一个“this”值引用正在构造的实例。非常整洁。

Overall, DBI strikes me as something of an intellectual curiousity. Coobird and others point out you can achieve the same effect with Arrays.asList, varargs methods, Google Collections, and the proposed Java 7 Collection literals. Newer JVM languages like Scala, JRuby, and Groovy also offer concise notations for list construction, and interoperate well with Java. Given that DBI clutters up the classpath, slows down class loading a bit, and makes the code a tad more obscure, I'd probably shy away from it. However, I plan to spring this on a friend who's just gotten his SCJP and loves good natured jousts about Java semantics! ;-) Thanks everyone!

7/2017: Baeldung很好地总结了双大括号初始化,并认为这是一种反模式。

2017年12月12日:@Basil Bourque指出,在新的Java 9中,你可以说:

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

这肯定是正确的选择。如果你还在使用以前的版本,可以看看谷歌Collections的ImmutableSet。


当前回答

执行以下测试类:

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文档中的详细信息。

其他回答

虽然这种语法很方便,但它也添加了大量的$0引用,因为这些引用是嵌套的,并且很难对初始化器进行步进调试,除非在每个初始化器上设置断点。出于这个原因,我只建议在普通的设置器,特别是设置为常量,以及匿名子类无关紧要的地方使用这个方法(比如不涉及序列化)。

到目前为止还没有指出的这种方法的一个特性是,因为创建了内部类,所以整个包含类都在其作用域中被捕获。这意味着只要你的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.

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

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

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 =列表。(猫,狗,马)