Wofür sind statische Blöcke zu gebrauchen? Hat jemand ein paar Verwendungsbeispiele? Bringen Sie welche Vorteile, z.B. bei der Performance? Nachteile?

Ein Member einer Klasse kann für eine Instanz oder für den Typ implementiert sein. Allein aus dieser Betrachtungsweise ergeben sich schon die Unterschiede bzw. Einsatzszenarien.

Hauptsächlich sind statische Blöcke dazu gedacht Code in einer Klasse bereit zustellen der unabhängig von einer konkreten Instanz ist. Konkrete Verwendung zB bei einer Fabrikmethode:

class Foo
{
    public static Foo Create()
    {
        return new Foo();
    }
}

Weiters werden statische Blöcke für die Erstellung von Singletons benötigt und ganz essentiell als Einstiegspunkt einer jeden Anwendung (static void Main).

Der "Klassiker" für eine statische Klasse ist System.Math. Es würde keinen Sinn machen davon eine Instanz zu erstellen wenn nur die (statischen) Methoden ausgeführt werden.

Bezüglich Performance sind statische Methodenaufrufe marginal schneller denn der Compiler kann eine call-Anweisung generieren während bei Instanz-Methoden ein callvirt erstellt wird. Dies deshalb weil beim callvirt geprüft wird ob die Instanz nicht null - sonst könnte es krachen.

Nachteile: Wenn sie für das verwendet werden für was sie gedacht sind gibt es keine Nachteile.

Ich beziehe micht mit der Antwort rein auf C# ;)

Ein static initializer block ist z.B. dann praktisch, wenn du eine statische Variable mit etwas initialisieren willst, was eine checked Exception wirft.

private static final File tmpFile = File.createTempFile("foo", ".tmp");

würde z.B. nicht kompilieren, da createTempFile() eine IOException wirft. Du kannst einen static initializer Block verwenden, um die Exception zu behandeln, also entweder in eine unchecked Exception umzuwandeln, oder die variable mit null zu belegen, oder was auch immer gerade sinnvoll ist:

private static final File tmpFile;
 
static {
 try {
  tmpFile = File.createTempFile("foo", ".tmp");
 } catch (final IOException e) {
  throw new RuntimeException(e);
 }
}

Hauptsächlich sind statische Blöcke dazu gedacht beim ersten Laden der Klasse ausgeführt zu werden. Im Gegensatz zu Konstruktoren sind sie nicht vererbbar. In diesem Beispiel wird foo beim Laden der Klasse auf 998877 gesetzt, sobald die Initialisierung vollständig ist:

public class test
    {
    static int foo = 12345;

    static
 {
 foo = 998877;
 }
    }

Hierbei werden die statischen Initialiser so ausgeführt, wie sie der Reihenfolge nach im Code benutzt wurden. Hier gibt es jedoch auch einige Einschränkungen. So können in static blocks keine checked exceptions, kein return statement und keine this oder super keywords gebraucht werden.

Einige sind dabei der Meinung, dass das lediglich eine nervige Eigenart von Java ist, da Java keine first-class Klassen besitzt.

PS: Ich bin kein Java Anwender, von daher korrigiert mich bitte, wenn ich allzu falsch liege!

static-Blöcke der Marke

class Foo {
{
// tu etwas Statisches
}
}

zerhacken den Kontrollfluss einer Anwendung. Ich sehe keinen Anwendungsfall, den man nicht auch ohne dieses Konstrukt lösen könnte. Mir würde ein bischen Augenmaß bei dem Einsatz dieser speziellen Konstrukte gefallen. Meine Empfehlung: Finger weg.

Nettes Beispiel: Date

Für Datumskonstanten muss man ja nun den Umweg über ein Calendar oder zumindest über ein paar (deprecated) Setter Aufrufe machen.

Man braucht also mehr als eine Zeile. Wenn man trotzdem den Vorteil von Konstanten haben will, (static final macht intern noch ein paar nette Dinge IIRC) muss man über diese Initializer-Blöcke gehen.

Man kann natürlich auch eine statische Fabrik bauen, dann *braucht* man sie nicht. Je nach Geschmack halt, aber gut sind sie dafür!

noch zwei Beispiele:
ähnlich wie bei fenchurch oder deexem zum Belegen einer static final Variable mit einem etwas komplexerem Objekt

private static final Map<String, String> DATA_MAP;
static {
 Map<String, String> tmp = new HashMap<String, String>();
 tmp.put("a", "1");
 tmp.put("b", "2");
 DATA_MAP = tmp;
}

zweites Beispiel ist JDBC. Beim Laden einer konkreten Driver-Klasse meldet sich diese in einem statischen Code-Block beim DriverManager an und ist danach verfügbar.
So z.B. bei HSQL:

static {
    try {
        DriverManager.registerDriver(new JDBCDriver());
    } catch (Exception e) {
    }
}

Das ist der Grund, warum man den Driver erst mit Class.forName() laden muss.