其实很不一样:

声明发生在构建之前。因此，如果在两个位置都初始化了变量(本例中为b)，构造函数的初始化将取代在类级别所做的初始化。

所以在类级别声明变量，在构造函数中初始化它们。

使用依赖注入或延迟初始化总是更可取的，已经在其他回答中详细解释过了。

当你不想或不能使用这些模式时，对于基元数据类型，有三个令人信服的原因，我可以想到为什么最好在构造函数之外初始化类属性:

避免重复=如果你有多个构造函数，或者当你需要添加更多构造函数时，你将不必在所有构造函数体中重复初始化; 改进的可读性=你可以很容易地从类外部判断哪些变量需要初始化; 减少代码行数=在声明时每执行一次初始化，构造函数中就会减少一行。

我认为这几乎只是一个品味问题，只要初始化是简单的，不需要任何逻辑。

如果不使用初始化块，构造函数方法会更脆弱一些，因为如果稍后添加第二个构造函数而忘记在那里初始化b，则只有在使用最后一个构造函数时才会得到一个空b。

有关Java中初始化的更多细节，请参阅http://java.sun.com/docs/books/tutorial/java/javaOO/initial.html(以及关于初始化器块和其他不为人所知的初始化特性的解释)。

例2不太灵活。如果您添加了另一个构造函数，则需要记住在该构造函数中实例化字段。直接实例化字段，或者在getter中引入延迟加载。

如果实例化需要的不仅仅是一个简单的new，请使用初始化块。不管使用的构造函数是什么，这个函数都将运行。如。

public class A {
    private Properties properties;

    {
        try {
            properties = new Properties();
            properties.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("file.properties"));
        } catch (IOException e) {
            throw new ConfigurationException("Failed to load properties file.", e); // It's a subclass of RuntimeException.
        }
    }

    // ...

}

我个人的“原则”(几乎从未被打破)是:

的开头声明所有变量 一块 使所有变量为final，除非它们 不能 每行声明一个变量 永远不要在某处初始化变量 宣布 只初始化a中的东西 构造函数时使用 的构造函数 初始化

我的代码是这样的:

public class X
{
    public static final int USED_AS_A_CASE_LABEL = 1; // only exception - the compiler makes me
    private static final int A;
    private final int b;
    private int c;

    static 
    { 
        A = 42; 
    }

    {
        b = 7;
    }

    public X(final int val)
    {
        c = val;
    }

    public void foo(final boolean f)
    {
        final int d;
        final int e;

        d = 7;

        // I will eat my own eyes before using ?: - personal taste.
        if(f)
        {
            e = 1;
        }
        else
        {
            e = 2;
        }
    }
}

This way I am always 100% certain where to look for variables declarations (at the start of a block), and their assignments (as soon as it makes sense after the declaration). This winds up potentially being more efficient as well since you never initialize a variable with a value that is not used (for example declare and init vars and then throw an exception before half of those vars needed to have a value). You also do not wind up doing pointless initialization (like int i = 0; and then later on, before "i" is used, do i = 5;.

我非常重视一致性，所以遵循这个“规则”是我一直在做的事情，它使处理代码变得更容易，因为你不需要到处寻找东西。

你的里程可能会有所不同。

另一种选择是使用依赖注入。

class A{
   B b;

   A(B b) {
      this.b = b;
   }
}

This removes the responsibility of creating the B object from the constructor of A. This will make your code more testable and easier to maintain in the long run. The idea is to reduce the coupling between the two classes A and B. A benefit that this gives you is that you can now pass any object that extends B (or implements B if it is an interface) to A's constructor and it will work. One disadvantage is that you give up encapsulation of the B object, so it is exposed to the caller of the A constructor. You'll have to consider if the benefits are worth this trade-off, but in many cases they are.