static從Java1.0開始便是Java中的關鍵字，用于表征靜態屬性或方法。它也得到了廣泛的應用，在業務中定義XXXUtil是一種常規的模式，甚至是比較知名的類庫（比如Apache Common Lang3）中都大量使用這種模式。這個模式確實帶來了很大的便利性，但是為什么我不提倡使用static呢？主要有以下幾個方面的原因：

static是反設計模式的

作為C系語言，static起源于C中的static，但是和C中的static語義卻很不一樣，根據《JLS 8.3.1.1》中的描述，static主要有以下語義：

If a field is declaredstatic, there exists exactly one incarnation of the field, no matter how many instances (possibly zero) of the class may eventually be created. A static field, sometimes called a class variable, is incarnated when the class is initialized.

static區別于對象，默認是和class關聯的。因此，常見的面向對象的技巧（比如繼承、多態）無法很好地應用到static的方法上，除了函數重載（overload）以外，static方法無法很好地享受面向對象帶來的便利性。static只是一種C中面向過程編程思想的延伸，在泛型成為高級語言標配的今天，我認為面向過程的編程方法不應該再被提倡了。這樣說比較抽象，可以用下面的例子來進行解釋，假設我們需要對LocalDataTime進行格式化：

public final class DateFormatUtil {private DateFormatUtil() {throw new IllegalStateException();}public static String format(LocalDateTime time) {if (time != null) {return time.format(DateTimeFormatter.ISO_DATE);}return "";} }//public final class DateFormatter implements Function<LocalDateTime, String> {private final DateTimeFormatter formatter;public DateFormatter(@NonNull DateTimeFormatter formatter) {this.formatter = formatter;}@Overridepublic String apply(LocalDateTime time) {if (time != null) {return time.format(formatter);}return "";} }

這兩種方式實現的功能是相同的，但是第二種方式相比于第一種方式，我覺得至少有幾點好處：

使用non-static的方式更方便擴展。在對外暴露的接口一致的情況下，第二種方法可以在不影響源代碼的情況下實現不同格式的格式化；但是用static的方式，要么將實現暴露出去，通過將DateTimeFormatter作為參數傳進來，要么通過不同的方法簽名來實現，兩種方式顯然都不夠優雅。

類型參數的約束比方法簽名的約束更有效，調用方通過類型參數能很好地知道方法到底要干什么，實現方也能更好地遵守規范去實現接口，兩者之間保持最小驚奇原則。

static不利于對類的精細化控制

在Java中，static的變量是和class綁定在一起的，也就是說在垃圾回收的過程中，除非class被回收掉，那么static的變量不會被垃圾回收。因此，在通常情況下，為了節約內存，降低GC壓力，Java應用程序中不應該存在太多的static的屬性（static final的編譯期常量除外，當然也不能過大）。

如果一個方法很復雜，涉及到的狀態很多（比較典型的比如JSON解析），就會涉及到很復雜的狀態轉移，也會需要很多的變量去維護這些狀態，那么這個時候如果用static的方法，那么所有的變量都必須是static的，這顯然和我們上面提到的原則是相違背的。static的變量其實就是全局變量，稍有經驗的開發都會知道，在大型工程中使用全局變量一定要非常謹慎。

// 使用jackson解析json private final ObjectMapper objectMapper = new ObjectMapper(); // 使用gson解析json private final Gson gson = new Gson(); // 兩大主流json框架的API設計，對比某國產xjson的API，實在是一言難盡

退一步說，如果我們需要通過static來實現全局變量或者全局方法的效果，完全可以通過單例模式來實現，況且現在主流的IoC框架（比如Spring、Guice）要實現這一點是如此的簡單。

不代表完全不使用static

使用static雖然有很多局限，但任何東西總是優點和缺點并存的，不能因為局限的存在就完全進行否定，至少在某些情況下，我認為使用static是非常合適的：

使用static方法來暴露類的構造工廠方法，比如String.valueOf()， LocalDateTime.now()，關于這一點，可以參考《Effective Java》第二章第一節的內容；

對于常量，使用static final進行修飾（要么non-static， 要么static final， 避免單獨static）；

如果一個方法所有狀態都可以封閉在棧內，變量不會逃逸到方法外，也可以使用static。

//guava中的字符串連接API Joiner.on("nt").withKeyValueSeparator('=').join(System.getProperties());

總結

以上是生活随笔為你收集整理的java aio为什么不稳定_为什么我不提倡在Java中使用static的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。