Why are static variables considered evil

Question

I am a Java programmer who is new to the corporate world  Recently I ve developed an application using Groovy and Java  All through the code I wrote used quite a good number of statics  I was asked by the senior technical lot to cut down on the number of statics used  I ve googled about the same  and I find that many programmers are fairly against using static variables   I find static variables more convenient to use  And I presume that they are efficient too  please correct me if I am wrong   because if I had to make 10 000 calls to a function within a class  I would be glad to make the method static and use a straightforward Class methodCall   on it instead of cluttering the memory with 10 000 instances of the class  right   Moreover statics reduce the inter-dependencies on the other parts of the code  They can act as perfect state holders  Adding to this I find that statics are widely implemented in some languages like Smalltalk and Scala  So why is this oppression for statics prevalent among programmers  especially in the world of Java    PS  please do correct me if my assumptions about statics are wrong

User · Answer

There are plenty of good answers here  adding to it    Memory   Static variables are live as long as the class loader lives in general till VM dies   but this is only in-case of bulk objects references stored as static   Modularization  consider concepts like IOC  dependencyInjection  proxy etc   All are completely against tightly coupling static implementations   Other Con s  Thread Safety  Testability

User · Answer

All the answers above show why statics are bad  The reason they are evil is because it gives the false impression that you are writing object oriented code  when in fact you are not  That is just plain evil

User · Answer

Static variables most importantly creates problem with security of data  any time changed anyone can change direct access without object  etc    For further info read this Thanks

User · Answer

The issue of  Statics being evil  is more of an issue about global state  The appropriate time for a variable to be static  is if it does not ever have more than one state  IE tools that should be accessible by the entire framework and always return the same results for the same method calls are never  evil  as statics  As to your comment      I find static variables more convenient to use  And I presume that they are efficient too   Statics are the ideal and efficient choice for variables classes that do not ever change   The problem with global state is the inherent inconsistency that it can create  Documentation about unit tests often address this issue  since any time there is a global state that can be accessed by more than multiple unrelated objects  your unit tests will be incomplete  and not  unit  grained  As mentioned in this article about global state and singletons  if object A and B are unrelated  as in one is not expressly given reference to another   then A should not be able to affect the state of B   There are some exceptions to the ban global state in good code  such as the clock  Time is global  and--in some sense--it changes the state of objects without having a coded relationship

User · Answer

My   02 is that several of these answers are confusing the issue  rather than saying  statics are bad  I think its better to talk about scoping and instances   What I would say is that a static is a  class  variables - it represenst a value that is shared across all instances of that class  Typically it should be scoped that way as well  protected or private to class and its instances    If you plan to put class-level behavior around it and expose it to other code  then a singleton may be a better solution to support changes in the future  as  Jessica suggested   This is because you can use interfaces at the instance singleton level in ways that you can not use at the class level - in particular inheritance   Some thoughts on why I think some of the aspects in other answers are not core to the question     Statics are not  global   In Java scoping is controlled separately from static instance    Concurrency is no less dangerous for statics than instance methods  It s still state that needs to be protected  Sure you may have 1000 instances with an instance variable each and only one static variable  but if the code accessing either isn t written in a thread-safe way you are still screwed - it just may take a little longer for you to realize it   Managing life cycle is an interesting argument  but I think it s a less important one  I don t see why its any harder to manage a pair of class methods like init   clear   than the creation and destroying of a singleton instance  In fact  some might say a singleton is a little more complicated due to GC   PS  In terms of Smalltalk  many of its dialects do have class variables  but in Smalltalk classes are actually instances of Metaclass so they are really are variables on the Metaclass instance  Still  I would apply the same rule of thumb  If they are being used for shared state across instances then ok  If they are supporting public functionality you should look at a Singleton  Sigh  I sure do miss Smalltalk

User · Answer

I find static variables more convenient to use  And I presume that they are efficient too  Please correct me if I am wrong  because if I had to make 10 000 calls to a function within a class  I would be glad to make the method static and use a straightforward class methodCall   on it instead of cluttering the memory with 10 000 instances of the class  Right    I see what you think  but a simple Singleton pattern will do the same without having to instantiate 10 000 objects   static methods can be used  but only for functions that are related to the object domain and do not need or use internal properties of the object   ex   public class WaterContainer       private int size      private int brand         etc      public static int convertToGallon int liters          public static int convertToLiters int gallon

User · Answer

everything  can   have its purpose  if you have bunch of threads that needs to share cache data and also all accessible memory  so you dont split into contexts within one JVM  the static is best choice-  of course you can force just one instance  but why  i find some of the comments in this thread evil  not the statics

User · Answer

I ve played with statics a lot and may I give you a slightly different answer--or maybe a slightly different way to look at it   When I ve used statics in a class  Members and methods both  I eventually started to notice that my class is actually two classes sharing responsibility--there is the  Static  part which acts a lot like a singleton and there is the non-static part  a normal class    As far as I know you can always separate those two classes completely by just selecting all the statics for one class and non-statics for the other   This used to happen a lot when I had a static collection inside a class holding instances of the class and some static methods to manage the collection   Once you think about it  it s obvious that your class is not doing  Just one thing   it s being a collection and the doing something completely different   Now  let s refactor the problem a little  If you split your class up into one class where everything is static and another which is just a  Normal Class  and forget about the  Normal Class  then your question becomes purely Static class vs Singleton which is addressed in length here  and probably a dozen other questions

User · Answer

a  Reason about programs   If you have a small- to midsize-program  where the static variable Global foo is accessed  the call to it normally comes from nowhere - there is no path  and therefore no timeline  how the variable comes to the place  where it is used  Now how do I know who set it to its actual value  How do I know  what happens  if I modify it right now  I have grep over the whole source  to collect all accesses  to know  what is going on    If you know how you use it  because you just wrote the code  the problem is invisible  but if you try to understand foreign code  you will understand    b  Do you really only need one   Static variables often prevent multiple programs of the same kind running in the same JVM with different values  You often don t foresee usages  where more than one instance of your program is useful  but if it evolves  or if it is useful for others  they might experience situations  where they would like to start more than one instance of your program    Only more or less useless code which will not be used by many people over a longer time in an intensive way might go well with static variables

User · Answer

In my opinion it s hardly ever about performance  it s about design  I don t consider the use of static methods wrong as apposed of the use of static variables  but I guess you are actually talking about method calls     It s simply about how to isolate logic and give it a good place  Sometimes that justifies using static methods of which java lang Math is a good example  I think when you name most of your classes XxxUtil or Xxxhelper you d better reconsider your design

User · Answer

Summarising few basic Advantages  amp  Disadvantages of using Static methods in Java   Advantages    Globally accessible i e  not tied with any particular object instance  One instance per JVM  Can be accessed by using class name  No object require   Contains a single value applicable to all instances  Load up on JVM startup and dies when JVM shuts down  They doesn t modify state of Object    Disadvantages    Static members are always part of memory whether they are in use or not  You can not control creation and destruction of static variable  Usefully they have been created at program loading and destroyed when program unload  or when JVM shuts down    You can make statics thread safe using synchronize but you need some extra efforts  If one thread change value of a static variable that can possibly break functionality of other threads  You must know    static    before using it  You cannot override static methods  Serialization doesn t work well with them  They don t participate in runtime polymorphism  There is a memory issue  to some extent but not much I guess  if a large number of static variables methods are used  Because they will not be Garbage Collected until program ends   Static methods are hard to test too

User · Answer

Yet another reason  fragility   If you have a class  most people expect to be able to create it and use it at will   You can document it s not the case  or protect against it  singleton factory pattern  - but that s extra work  and therefore an additional cost  Even then  in a big company  chances are someone will try at some point to use your class without fully paying attention to all the nice comments or the factory   If you re using static variables a lot  that will break  Bugs are expensive   Between a  0001  performance improvement and robustness to change by potentially clueless developers  in a lot of cases robustness is the good choice

User · Answer

I think excessive uses of global variables with static keyword will also leads to memory leakage at some point of instance in the applica

User · Answer

Its not very object oriented  One reason statics might be considered  evil  by some people is they are contrary the object-oriented paradigm  In particular  it violates the principle that data is encapsulated in objects  that can be extended  information hiding  etc   Statics  in the way you are describing using them  are essentially to use them as a global variable to avoid dealing with issues like scope  However  global variables is one of the defining characteristics of procedural or imperative programming paradigm  not a characteristic of  good  object oriented code  This is not to say the procedural paradigm is bad  but I get the impression your supervisor expects you to be writing  good object oriented code  and you re really wanting to write  good procedural code     There are many gotchyas in Java when you start using statics that are not always immediately obvious  For example  if you have two copies of your program running in the same VM  will they shre the static variable s value and mess with the state of each other  Or what happens when you extend the class  can you override the static member  Is your VM running out of memory because you have insane numbers of statics and that memory cannot be reclaimed for other needed instance objects   Object Lifetime  Additionally  statics have a lifetime that matches the entire runtime of the program  This means  even once you re done using your class  the memory from all those static variables cannot be garbage collected  If  for example  instead  you made your variables non-static  and in your main   function you made a single instance of your class  and then asked your class to execute a particular function 10 000 times  once those 10 000 calls were done  and you delete your references to the single instance  all your static variables could be garbage collected and reused    Prevents certain re-use  Also  static methods cannot be used to implement an interface  so static methods can prevent certain object oriented features from being usable   Other Options  If efficiency is your primary concern  there might be other better ways to solve the speed problem than considering only the advantage of invocation being usually faster than creation  Consider whether the transient or volatile modifiers are needed anywhere  To preserve the ability to be inlined  a method could be marked as final instead of static  Method parameters and other variables can be marked final to permit certain compiler optimiazations based on assumptions about what can change those variables  An instance object could be reused multiple times rather than creating a new instance each time   There may be compliler optimization switches that should be turned on for the app in general  Perhaps  the design should be set up so that the 10 000 runs can be multi-threaded and take advantage of multi-processor cores  If portablity isn t a concern  maybe a native method would get you better speed than your statics do   If for some reason you do not want multiple copies of an object  the singleton design pattern  has advantages over static objects  such as thread-safety  presuming your singleton is coded well   permitting lazy-initialization  guaranteeing the object has been properly initialized when it is used  sub-classing  advantages in testing and refactoring your code  not to mention  if at some point you change your mind about only wanting one instance of an object it is MUCH easier to remove the code to prevent duplicate instances than it is to refactor all your static variable code to use instance variables  I ve had to do that before  its not fun  and you end up having to edit a lot more classes  which increases your risk of introducing new bugs   so much better to set things up  right  the first time  even if it seems like it has its disadvantages  For me  the re-work required should you decide down the road you need multiple copies of something is probably one of most compelling reasons to use statics as infrequently as possible  And thus I would also disagree with your statement that statics reduce inter-dependencies  I think you will end up with code that is more coupled if you have lots of statics that can be directly accessed  rather than an object that  knows how to do something  on itself

User · Answer

It might be suggested that in most cases where you use a static variable  you really want to be using the singleton pattern   The problem with global states is that sometimes what makes sense as global in a simpler context  needs to be a bit more flexible in a practical context  and this is where the singleton pattern becomes useful

User · Answer

Since no one  has mentioned it  concurrency  Static variables can surprise you if you have multiple threads reading and writing to the static variable  This is common in web applications  e g   ASP NET  and it can cause some rather maddening bugs  For example  if you have a static variable that is updated by a page  and the page is requested by two people at  nearly the same time   one user may get the result expected by the other user  or worse      statics reduce the inter-dependencies on the other parts of the code  They can act as perfect state holders   I hope you re prepared to use locks and deal with contention    Actually  Preet Sangha mentioned it

User · Answer

Suppose that if you have an application with many users and you have defined a static function that saves state within a static variable  then every user will modify the state of other users

User · Answer

If you are using the    static    keyword without the    final    keyword  this should be a signal to carefully consider your design  Even the presence of a    final    is not a free pass  since a mutable static final object can be just as dangerous   I would estimate somewhere around 85  of the time I see a    static    without a    final     it is WRONG  Often  I will find strange workarounds to mask or hide these problems   Please don   t create static mutables  Especially Collections  In general  Collections should be initialized when their containing object is initialized and should be designed so that they are reset or forgotten about when their containing object is forgotten   Using statics can create very subtle bugs which will cause sustaining engineers days of pain  I know  because I   ve both created and hunted these bugs   If you would like more details  please read on     Why Not Use Statics   There are many issues with statics  including writing and executing tests  as well as subtle bugs that are not immediately obvious   Code that relies on static objects can   t be easily unit tested  and statics can   t be easily mocked  usually    If you use statics  it is not possible to swap the implementation of the class out in order to test higher level components  For example  imagine a static CustomerDAO that returns Customer objects it loads from the database  Now I have a class CustomerFilter  that needs to access some Customer objects  If CustomerDAO is static  I can   t write a test for CustomerFilter without first initializing my database and populating useful information   And database population and initialization takes a long time  And in my experience  your DB initialization framework will change over time  meaning data will morph  and tests may break  IE  imagine Customer 1 used to be a VIP  but the DB initialization framework changed  and now Customer 1 is no longer VIP  but your test was hard-coded to load Customer 1     A better approach is to instantiate a CustomerDAO  and pass it into the CustomerFilter when it is constructed   An even better approach would be to use Spring or another Inversion of Control framework   Once you do this  you can quickly mock or stub out an alternate DAO in your CustomerFilterTest  allowing you to have more control over the test   Without the static DAO  the test will be faster  no db initialization  and more reliable  because it won   t fail when the db initialization code changes   For example  in this case ensuring Customer 1 is and always will be a VIP  as far as the test is concerned   Executing Tests  Statics cause a real problem when running suites of unit tests together  for example  with your Continuous Integration server   Imagine a static map of network Socket objects that remains open from one test to another  The first test might open a Socket on port 8080  but you forgot to clear out the Map when the test gets torn down  Now when a second test launches  it is likely to crash when it tries to create a new Socket for port 8080  since the port is still occupied   Imagine also that Socket references in your static Collection are not removed  and  with the exception of WeakHashMap  are never eligible to be garbage collected  causing a memory leak   This is an over-generalized example  but in large systems  this problem happens ALL THE TIME  People don   t think of unit tests starting and stopping their software repeatedly in the same JVM  but it is a good test of your software design  and if you have aspirations towards high availability  it is something you need to be aware of   These problems often arise with framework objects  for example  your DB access  caching  messaging  and logging layers  If you are using Java EE or some best of breed frameworks  they probably manage a lot of this for you  but if like me you are dealing with a legacy system  you might have a lot of custom frameworks to access these layers   If the system configuration that applies to these framework components changes between unit tests  and the unit test framework doesn   t tear down and rebuild the components  these changes can   t take effect  and when a test relies on those changes  they will fail   Even non-framework components are subject to this problem  Imagine a static map called OpenOrders  You write one test that creates a few open orders  and checks to make sure they are all in the right state  then the test ends  Another developer writes a second test which puts the orders it needs into the OpenOrders map  then asserts the number of orders is accurate  Run individually  these tests would both pass  but when run together in a suite  they will fail   Worse  failure might be based on the order in which the tests were run   In this case  by avoiding statics  you avoid the risk of persisting data across test instances  ensuring better test reliability   Subtle Bugs  If you work in high availability environment  or anywhere that threads might be started and stopped  the same concern mentioned above with unit test suites can apply when your code is running on production as well   When dealing with threads  rather than using a static object to store data  it is better to use an object initialized during the thread   s startup phase  This way  each time the thread is started  a new instance of the object  with a potentially new configuration  is created  and you avoid data from one instance of the thread bleeding through to the next instance   When a thread dies  a static object doesn   t get reset or garbage collected  Imagine you have a thread called    EmailCustomers     and when it starts it populates a static String collection with a list of email addresses  then begins emailing each of the addresses  Lets say the thread is interrupted or canceled somehow  so your high availability framework restarts the thread  Then when the thread starts up  it reloads the list of customers  But because the collection is static  it might retain the list of email addresses from the previous collection  Now some customers might get duplicate emails   An Aside  Static Final  The use of    static final    is effectively the Java equivalent of a C  define  although there are technical implementation differences  A C C    define is swapped out of the code by the pre-processor  before compilation  A Java    static final    will end up memory resident on the stack  In that way  it is more similar to a    static const    variable in C   than it is to a  define   Summary  I hope this helps explain a few basic reasons why statics are problematic up  If you are using a modern Java framework like Java EE or Spring  etc  you may not encounter many of these situations  but if you are working with a large body of legacy code  they can become much more frequent

User · Answer

There are 2 main problems with static variables    Thread Safety - static resources are by definition not thread-safe Code Implicity - You do not know when a static variables is instantiated and whether or not it will be instantiated before another static variable

User · Answer

Static variables are generally considered bad because they represent global state and are therefore much more difficult to reason about   In particular  they break the assumptions of object-oriented programming   In object-oriented programming  each object has its own state  represented by instance  non-static  variables   Static variables represent state across instances which can be much more difficult to unit test   This is mainly because it is more difficult to isolate changes to static variables to a single test   That being said  it is important to make a distinction between regular static variables  generally considered bad   and final static variables  AKA constants  not so bad

User · Answer

Static variables represent global state  That s hard to reason about and hard to test  if I create a new instance of an object  I can reason about its new state within tests  If I use code which is using static variables  it could be in any state - and anything could be modifying it   I could go on for quite a while  but the bigger concept to think about is that the tighter the scope of something  the easier it is to reason about  We re good at thinking about small things  but it s hard to reason about the state of a million line system if there s no modularity  This applies to all sorts of things  by the way - not just static variables

User · Answer

There are two main questions in your post   First  about static variables  Static variables are completelly unnecesary and it s use can be avoided easily  In OOP languajes in general  and in Java particularlly  function parameters are pased by reference  this is to say  if you pass an object to a funciont  you are passing a pointer to the object  so you dont need to define static variables since you can pass a pointer to the object to any scope that needs this information  Even if this implies that yo will fill your memory with pointers  this will not necesary represent a poor performance because actual memory pagging systems are optimized to handle with this  and they will maintain in memory the pages referenced by the pointers you passed to the new scope  usage of static variables may cause the system to load the memory page where they are stored when they need to be accessed  this will happen if the page has not been accesed in a long time   A good practice is to put all that static stuf together in some little  configuration clases   this will ensure the system puts it all in the same memory page   Second  about static methods  Static methods are not so bad  but they can quickly reduce performance  For example  think about a method that compares two objects of a class and returns a value indicating which of the objects is bigger  tipical comparison method  this method can be static or not  but when invoking it the non static form will be more eficient since it will have to solve only two references  one for each object  face to the three references that will have to solve the static version of the same method  one for the class plus two  one for each object   But as I say  this is not so bad  if we take a look at the Math class  we can find a lot of math functions defined as static methods  This is really more eficient than putting all these methods in the class defining the numbers  because most of them are rarelly used and including all of them in the number class will cause the class to be very complex and consume a lot of resources unnecesarilly   In concluson  Avoid the use of static variables and find the correct performance equilibrium when dealing with static or non static methods   PS  Sorry for my english

User · Answer

Static variables are not good nor evil  They represent attributes that describe the whole class and not a particular instance  If you need to have a counter for all the instances of a certain class  a static variable would be the right place to hold the value   Problems appear when you try to use static variables for holding instance related values

User · Answer

Evil is a subjective term   You don t control statics in terms of creation and destruction  They live at the behest of the program loading and unloading      Since statics live in one space  all threads wishing to use them must go through access control that you have to manage  This means that programs are more coupled and this change is harder to envisage and manage  like J Skeet says   This leads to problems of isolating change impact and thus affects how testing is managed   These are the two main issues I have with them

User · Answer

There s nothing wrong with static variables per se   It s just the Java syntax that s broken   Each Java class actually defines two structures- a singleton object which encapsulates static variables  and an instance   Defining both in the same source block is pure evil  and results in a code that s hard to read   Scala did that right

User · Answer

if I had to make 10 000 calls to a function within a class  I would be   glad to make the method static and use a straightforward   class methodCall   on it instead of cluttering the memory with 10 000   instances of the class  Right    You have to balance the need for encapsulating data into an object with a state  versus the need of simply computing the result of a function on some data      Moreover statics reduce the inter-dependencies on the other parts of the code    So does encapsulation  In large applications  statics tend to produce spaghetti code and don t easily allow refactoring or testing   The other answers also provide good reasons against excessive use of statics

User · Answer

Seems to me that you re asking about static variables but you also point out static methods in your examples   Static variables are not evil - they have its adoption as global variables like constants in most cases combined with final modifier  but as it said don t overuse them   Static methods aka utility method  It isn t generally a bad practice to use them but major concern is that they might obstruct testing   As a example of great java project that use a lot of statics and do it right way please look at Play  framework  There is also discussion about it in SO   Static variables methods combined with static import are also widely used in libraries that facilitate declarative programming in java like  make it easy or Hamcrest  It wouldn t be possible without a lot of static variables and methods   So static variables  and methods  are good but use them wisely

User · Answer

I have just summarized some of the points made in the answers  If you find anything wrong please feel free to correct it  Scaling  We have exactly one instance of a static variable per JVM  Suppose we are developing a library management system and we decided to put the name of book a static variable as there is only one per book  But if system grows and we are using multiple JVMs then we dont have a way to figure out which book we are dealing with  Thread-Safety  Both instance variable and static variable need to be controlled when used in multi threaded environment  But in case of an instance variable it does not need protection unless it is explicitly shared between threads but in case of a static variable it is always shared by all the threads in the process  Testing  Though testable design does not equal to good design but we will rarely observe a good design that is not testable  As static variables represent global state and it gets very difficult to test them  Reasoning about state  If I create a new instance of a class then we can reason about the state of this instance but if it is having static variables then it could be in any state  Why  Because it is possible that the static variable has been modified by some different instance as static variable is shared across instances  Serialization  Serialization also does not work well with them  Creation and destruction  Creation and destruction of static variables can not be controlled  Usually they are created and destroyed at program loading and unloading time  It means they are bad for memory management and also add up the initialization time at start up  But what if we really need them  But sometimes we may have a genuine need of them  If we really feel the need of many static variables that are shared across the application then one option is to make use of Singleton Design pattern which will have all these variables  Or we can create some object which will have these static variable and can be passed around  Also if the static variable is marked final it becomes a constant and value assigned to it once cannot be changed  It means it will save us from all the problems we face due to its mutability

User · Answer

No  Global states are not evil per se  But we have to see your code to see if you used it properly  It is quite possible that a newbie abuses global states  just like he would abuses every language feature   Global states are absolute necessity  We cannot avoid global states  We cannot avoid reasoning about global states  - If we care to understand our application semantics    People who try to get rid of global states for the sake of it  inevitably end up with a much more complex system - and the global states are still there  cleverly idiotically disguised under many layers of indirections  and we still have to reason about global states  after unwrapping all the indirections   Like the Spring people who lavishly declare global states in xml and think somehow it s superior    Jon Skeet if I create a new instance of an object now you have two things to reason about - the state within the object  and the state of the environment hosting the object

User · Answer

From my point of view static variable should be only read only data or variables created by convention   For example we have a ui of some project  and we have a list of countries  languages  user roles  etc  And we have class to organize this data  we absolutely sure that app will not work without this lists  so the first that we do on app init is checking this list for updates and getting this list from api  if needed   So we agree that this data is  always  present in app  It is practically read only data so we don t need to take care of it s state - thinking about this case we really don t want to have a lot of instances of those data - this case looks a perfect candidate to be static

[java] Why are static variables considered evil?

Examples related to java

Examples related to static