它不太面向對象：有些人認為靜力學是“邪惡”的原因之一是它們與面向對象范式。特別是，它違反了數據封裝在對象(可以擴展、信息隱藏等)中的原則。靜力學，以你描述的方式使用它們，本質上是將它們作為一個全局變量來使用，以避免處理像范圍這樣的問題。然而，全局變量是過程或命令式編程范式的定義特征之一，而不是面向對象代碼的“好”特性。這并不是說過程范式是糟糕的，但我得到的印象是，您的主管希望您編寫“良好的面向對象的代碼”，并且您確實希望編寫“良好的過程代碼”。
當您開始使用靜力學時，Java中有許多問題并不總是顯而易見的。例如，如果程序的兩個副本運行在同一個VM中，那么它們會不會SHRE靜態變量的值和彼此狀態的混亂？或者當您擴展類時，可以覆蓋靜態成員嗎？您的VM是否因為有大量的靜力學而耗盡內存，并且無法為其他所需的實例對象回收內存？
對象生命周期：此外，靜力學的生命周期與程序的整個運行時相匹配。這意味著，即使使用完類，也不能垃圾收集所有這些靜態變量的內存。例如，如果您將變量設置為非靜態變量，并且在main()函數中創建了類的單個實例，然后要求類執行特定函數10，000次，一旦完成這10，000次調用，并且刪除對單個實例的引用，則可以垃圾收集和重用所有靜態變量。
防止某些重復使用：此外，靜態方法不能用于實現接口，因此靜態方法可以阻止某些面向對象的特性可用。
其他備選方案：如果效率是您最關心的問題，那么可能還有其他更好的方法來解決速度問題，而不是僅僅考慮調用通常比創建更快的優點?？紤]是否在任何地方都需要瞬態或易失性修飾符。為了保持內聯的能力，方法可以標記為Final而不是靜態的。方法參數和其他變量可以標記為Final，以允許基于可以更改這些變量的假設進行某些編譯器優化?？梢远啻沃赜脤嵗龑ο?，而不是每次創建新實例。可能會有復雜優化開關，應該打開的應用程序在一般情況下。也許，設計應該設置，這樣就可以運行10，000次多線程，并利用多處理器內核。如果可移植性不是一個問題，也許一個本地的方法會讓你比你的靜力學更快。
如果由于某種原因不希望一個對象的多個副本，則單例設計模式，與靜態對象相比具有優勢，例如線程安全(假定您的單例代碼編寫得很好)、允許延遲初始化、確保對象在使用時被正確初始化、子類化、測試和重構代碼方面的優勢，更不用說，如果您在某一時刻改變了只想要一個對象實例的想法，那么刪除代碼以防止重復實例要比重構所有靜態變量代碼以使用實例變量容易得多。我以前不得不這樣做，這并不有趣，最后你不得不編輯更多的類，這就增加了引入新bug的風險…所以最好在第一次設置“正確”的東西，即使它似乎有它的缺點。對我來說，如果你決定在路上需要多個副本的話，你所需要的返工可能是盡可能不經常使用靜力學的最有說服力的原因之一。因此，我也不同意你所說的靜力學減少相互依賴的說法，我認為，如果你有很多可以直接訪問的靜力學，而不是一個“知道如何在自己身上做某事”的對象，你最終會得到更多耦合的代碼。
