This discussion is archived
9 Replies Latest reply: Nov 17, 2010 1:47 PM by jschellSomeoneStoleMyAlias RSS

Static variable

269490 Newbie
Currently Being Moderated
I have a question about static variables.
If you have a static varilable, the same variable is used for all occurances of the class, so even if there are 10 occurrances instantiated, there is only one of each static variable.
If you change the value of that static variable, it is know to all instances of that class.
What happens if the class is temporarily removed from the JVM because it is not being used? Then a new program instantiates it again.
Does the value of the static variable get set back to its original value or is the value kept somehow in the JVM?
  • 1. Re: Static variable
    796440 Guru
    Currently Being Moderated
    Once a class is unloaded, it's gone. If it's then loaded again by a different classloader (the only way it can be reloaded in the same JVM), it's a completely different class that just happens to have the same name and definition as the previous one. All the static variables start at their default values and all static initializations are run. Any previous values are lost.

    As for loading by a different JVM, since the variables exist only in memory and are not persisted back out to the jar or class file from which the class was loaded when you set them, of course it will see a fresh copy with initial values reset.
  • 2. Re: Static variable
    269490 Newbie
    Currently Being Moderated
    jverd wrote:
    Once a class is unloaded, it's gone. If it's then loaded again by a different classloader (the only way it can be reloaded in the same JVM), it's a completely different class that just happens to have the same name and definition as the previous one. All the static variables start at their default values and all static initializations are run. Any previous values are lost.

    As for loading by a different JVM, since the variables exist only in memory and are not persisted back out to the jar or class file from which the class was loaded when you set them, of course it will see a fresh copy with initial values reset.
    So then you can't use it as a common counter for multiple java programs or programs that run multiple times because you cannot be sure that the instance will always remain in the JVM.
  • 3. Re: Static variable
    796440 Guru
    Currently Being Moderated
    In a single JVM, once a class is loaded, it will only ever be unloaded if there are no reachable references to it or to the classloader that loaded it. You kind of have to go out of your way to unload a class. As long as a given app is running, you can rely on a static member variable as a counter.

    However, with regard to "running multiple times" or "multiple java programs", you need to understand that every time you run java.exe, you're creating a new process with it's own memory space and its own variables. MyClass in java.exe the first time you run it has nothing whatsoever to do with MyClass in java.exe the second time you run it.

    So, yes, you can be sure it will remain in the JVM, but no, it's not an instance, just a class. And running a program multiple times or running multiple programs has nothing to do with it "remaining" in the JVM, since it's not the same JVM.

    Edited by: jverd on Nov 16, 2010 10:54 AM
  • 4. Re: Static variable
    269490 Newbie
    Currently Being Moderated
    jverd wrote:
    In a single JVM, once a class is loaded, it will only ever be unloaded if there are no reachable references to it or to the classloader that loaded it. You kind of have to go out of your way to unload a class. As long as a given app is running, you can rely on a static member variable as a counter.

    However, with regard to "running multiple times" or "multiple java programs", you need to understand that every time you run java.exe, you're creating a new process with it's own memory space and its own variables. MyClass in java.exe the first time you run it has nothing whatsoever to do with MyClass in java.exe the second time you run it.

    So, yes, you can be sure it will remain in the JVM, but no, it's not an instance, just a class. And running a program multiple times or running multiple programs has nothing to do with it "remaining" in the JVM, since it's not the same JVM.

    Edited by: jverd on Nov 16, 2010 10:54 AM
    If you are running an application in an application server, then multiple programs can run in the same JVM. In that case, running a program multiple times will happen in the same JVM, won't it?

    BTW, what is your definition of an app?
  • 5. Re: Static variable
    796440 Guru
    Currently Being Moderated
    ttb999 wrote:
    jverd wrote:
    In a single JVM, once a class is loaded, it will only ever be unloaded if there are no reachable references to it or to the classloader that loaded it. You kind of have to go out of your way to unload a class. As long as a given app is running, you can rely on a static member variable as a counter.

    However, with regard to "running multiple times" or "multiple java programs", you need to understand that every time you run java.exe, you're creating a new process with it's own memory space and its own variables. MyClass in java.exe the first time you run it has nothing whatsoever to do with MyClass in java.exe the second time you run it.

    So, yes, you can be sure it will remain in the JVM, but no, it's not an instance, just a class. And running a program multiple times or running multiple programs has nothing to do with it "remaining" in the JVM, since it's not the same JVM.

    Edited by: jverd on Nov 16, 2010 10:54 AM
    If you are running an application in an application server, then multiple programs can run in the same JVM.
    Ah, okay. I thought you were talking about a standalone app.
    In that case, running a program multiple times will happen in the same JVM, won't it?
    Yes, but what do you mean by running it "multiple times"? Do you mean stopping and restarting it? Or do you mean having to entries for it in web.xml or wherever it is that the deployed apps are listed? Although I guess it doesn't matter, because in either case, it's still two completely separate apps.

    Even if you don't explicitly shutdown and restart your app, the container might be free to unload and reload your app. I'm not completely sure about that though. You might be able to rely on the class remaining loaded once your app has started up.

    If you want to rely on the counter across app server restarts, you'll have to persist it to a file or DB.

    If you want to rely on the counter across different concurrent invocations of your app (dues to multiple entries in web.xml), you'll probably have to persist it to a file or DB, although you might get away with putting that class's jar file in the lib directory that the app server shares across apps. I wouldn't recommend that though.

    If you want to rely on the counter across the app server reloading or stopping/restarting your app, you'll have to persist it to a file or DB, since each app invocation gets its own classloader subhierarchy under which any jars distributed normally with the app are loaded. Here too, you might be able to get away with putting that jar in the lib directory shared by all apps, but I would consider that an misuse of that classloader and would not recommend it.

    If you're wondering whether the app server is allowed to arbitrarily unload your app of its own accord, that I don't know.

    Edited by: jverd on Nov 16, 2010 11:29 AM
  • 6. Re: Static variable
    269490 Newbie
    Currently Being Moderated
    jverd wrote:
    ttb999 wrote:
    jverd wrote:
    In a single JVM, once a class is loaded, it will only ever be unloaded if there are no reachable references to it or to the classloader that loaded it. You kind of have to go out of your way to unload a class. As long as a given app is running, you can rely on a static member variable as a counter.

    However, with regard to "running multiple times" or "multiple java programs", you need to understand that every time you run java.exe, you're creating a new process with it's own memory space and its own variables. MyClass in java.exe the first time you run it has nothing whatsoever to do with MyClass in java.exe the second time you run it.

    So, yes, you can be sure it will remain in the JVM, but no, it's not an instance, just a class. And running a program multiple times or running multiple programs has nothing to do with it "remaining" in the JVM, since it's not the same JVM.

    Edited by: jverd on Nov 16, 2010 10:54 AM
    If you are running an application in an application server, then multiple programs can run in the same JVM.
    Ah, okay. I thought you were talking about a standalone app.
    In that case, running a program multiple times will happen in the same JVM, won't it?
    Yes, but what do you mean by running it "multiple times"? Do you mean stopping and restarting it? Or do you mean having to entries for it in web.xml or wherever it is that the deployed apps are listed? Although I guess it doesn't matter, because in either case, it's still two completely separate apps.

    Even if you don't explicitly shutdown and restart your app, the container might be free to unload and reload your app. I'm not completely sure about that though. You might be able to rely on the class remaining loaded once your app has started up.

    If you want to rely on the counter across app server restarts, you'll have to persist it to a file or DB.

    If you want to rely on the counter across different concurrent invocations of your app (dues to multiple entries in web.xml), you'll probably have to persist it to a file or DB, although you might get away with putting that class's jar file in the lib directory that the app server shares across apps. I wouldn't recommend that though.

    If you want to rely on the counter across the app server reloading or stopping/restarting your app, you'll have to persist it to a file or DB, since each app invocation gets its own classloader subhierarchy under which any jars distributed normally with the app are loaded. Here too, you might be able to get away with putting that jar in the lib directory shared by all apps, but I would consider that an misuse of that classloader and would not recommend it.

    If you're wondering whether the app server is allowed to arbitrarily unload your app of its own accord, that I don't know.

    Edited by: jverd on Nov 16, 2010 11:29 AM
    I'm just trying to understand when you would use class variables. Should you use them in individual java programs that instantiate multiple occurances of the same class or can they be used in systems that have multiple programs instantiating the same classes or using static classes?
    I've really only just stored the value in a database table if I want it to be available to multiple programs or for the same program run multiple times like in a JSP Action class but this is an approach people have been talking about and I am trying to understand when it can be used.
  • 7. Re: Static variable
    796440 Guru
    Currently Being Moderated
    ttb999 wrote:
    I'm just trying to understand when you would use class variables.
    When you want something that applies to the class as a whole. For instance, a logger that all instances and static methods can share, or a map of some keys to instances of that class.
    Should you use them in individual java programs that instantiate multiple occurances of the same class or can they be used in systems that have multiple programs instantiating the same classes or using static classes?
    I don't see what you're asking here, and I don't see that as an either/or proposition. And again, the "multiple programs" bit seems like you're missing something fundamental. MyClass.staticVar in one app or one invocation of an app is completely separate and independent from MyClass.staticVar in another app or another invocation of the same app.
    I've really only just stored the value in a database table if I want it to be available to multiple programs or for the same program run multiple times like in a JSP Action class but this is an approach people have been talking about and I am trying to understand when it can be used.
    Sorry, but without more context and more standard terminology, I can't give you a more concrete answer.
  • 8. Re: Static variable
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    ttb999 wrote:
    If you are running an application in an application server, then multiple programs can run in the same JVM. In that case, running a program multiple times will happen in the same JVM, won't it?

    BTW, what is your definition of an app?
    There seems to be a term definition problem there.

    A "process" is a independent entity. In the context of this discussion everything in one process is independent from any other process. Each VM is a process.

    http://en.wikipedia.org/wiki/Process_(computing)

    Normally 'application' equals 'process'. Thus windows notepad is a process and an application.

    A java application server does not run different 'processes' nor 'applications' as defined about.

    The term application in an application server has a different meaning in that it represents a different context within a single process. For java class loaders allow that differentiation. And as already noted different class loaders mean different instances of the same static variable.
  • 9. Re: Static variable
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    ttb999 wrote:
    I've really only just stored the value in a database table if I want it to be available to multiple programs or for the same program run multiple times like in a JSP Action class but this is an approach people have been talking about and I am trying to understand when it can be used.
    I suggest you explain your problem rather than trying to make a solution fit it.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points