static synchronized method

Discussion in 'Java' started by Ross, Jul 27, 2011.

  1. Ross

    Ross Guest

    If I have a method which is both static and synchronized, then can I
    guarantee that only one thread will be allowed in at once, even if I
    have multiple instances of the object in memory, one per thread?

    Cheers,

    Ross
     
    Ross, Jul 27, 2011
    #1
    1. Advertising

  2. Ross

    markspace Guest

    On 7/27/2011 6:31 AM, Ross wrote:
    > If I have a method which is both static and synchronized, then can I
    > guarantee that only one thread will be allowed in at once, even if I
    > have multiple instances of the object in memory, one per thread?



    Yes. The "synchronized" keyword on a static method synchronizes on the
    class object. Since all instances of that class share one class object,
    then there'll be only one thread, period, in that method at a time.

    There's a slight exception for class loaders which load load multiple
    instances of the same class object. Since all the static method does is
    synchronize on the class object, there may be be more than one thread,
    one per loaded class object, in those circumstances.

    There are some good reasons to have multiple class objects, but it's not
    really normal and would usually be considered an error in the class
    loader, just so you know.
     
    markspace, Jul 27, 2011
    #2
    1. Advertising

  3. Ross

    Henderson Guest

    On 27/07/2011 9:37 AM, markspace wrote:
    > On 7/27/2011 6:31 AM, Ross wrote:
    >> If I have a method which is both static and synchronized, then can I
    >> guarantee that only one thread will be allowed in at once, even if I
    >> have multiple instances of the object in memory, one per thread?

    >
    > Yes. The "synchronized" keyword on a static method synchronizes on the
    > class object. Since all instances of that class share one class object,
    > then there'll be only one thread, period, in that method at a time.
    >
    > There's a slight exception for class loaders which load load multiple
    > instances of the same class object. Since all the static method does is
    > synchronize on the class object, there may be be more than one thread,
    > one per loaded class object, in those circumstances.
    >
    > There are some good reasons to have multiple class objects, but it's not
    > really normal and would usually be considered an error in the class
    > loader, just so you know.


    Also, the likely reason for synchronizing a static method is to make
    sure operations it performs on mutable private static variables are
    atomic and don't suffer from data races. If there are two copies of the
    class via different classloaders, they get their own independent copies
    of those static variables as well as their own independent monitors, so
    their having separate monitors doesn't create an opportunity for a data
    race.

    The main concern, instead, is invariant violation when the design
    expects a singleton of some sort: a single global registry of some sort,
    a single global interning cache, a single INSTANCE reference to a single
    singleton instance such as what java.awt.Toolkit.getDefaultToolkit()
    returns, etc.; if there are suddenly two of a thing like that when the
    design calls for exactly one, then problems can ensue, but problems that
    have nothing to do with concurrency and data races.
     
    Henderson, Jul 27, 2011
    #3
  4. Ross

    Roedy Green Guest

    On Wed, 27 Jul 2011 06:31:29 -0700 (PDT), Ross <>
    wrote, quoted or indirectly quoted someone who said :

    >If I have a method which is both static and synchronized, then can I
    >guarantee that only one thread will be allowed in at once, even if I
    >have multiple instances of the object in memory, one per thread?


    Static methods sync on the class object, one per classloader, usually
    one per JVM.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    Most of computer code is for telling the computer
    what do if some very particular thing goes wrong.
     
    Roedy Green, Jul 27, 2011
    #4
  5. Ross

    lewbloch Guest

    Henderson wrote:
    > markspace wrote:
    >> Ross wrote:
    >>> If I have a method which is both static and synchronized, then can I
    >>> guarantee that only one thread will be allowed in at once, even if I
    >>> have multiple instances of the object in memory, one per thread?

    >
    >> Yes. The "synchronized" keyword on a static method synchronizes on the
    >> class object. Since all instances of that class share one class object,
    >> then there'll be only one thread, period, in that method at a time.
    >>
    >> There's a slight exception for class loaders which load load multiple
    >> instances of the same class object. Since all the static method does is
    >> synchronize on the class object, there may be be more than one thread,
    >> one per loaded class object, in those circumstances.
    >>
    >> There are some good reasons to have multiple class objects, but it's not
    >> really normal and would usually be considered an error in the class
    >> loader, just so you know.

    >
    > Also, the likely reason for synchronizing a static method is to make
    > sure operations it performs on mutable private static variables are
    > atomic and don't suffer from data races. If there are two copies of the
    > class via different classloaders, they get their own independent copies
    > of those static variables as well as their own independent monitors, so
    > their having separate monitors doesn't create an opportunity for a data
    > race.
    >
    > The main concern, instead, is invariant violation when the design
    > expects a singleton of some sort: a single global registry of some sort,
    > a single global interning cache, a single INSTANCE reference to a single
    > singleton instance such as what java.awt.Toolkit.getDefaultToolkit()
    > returns, etc.; if there are suddenly two of a thing like that when the
    > design calls for exactly one, then problems can ensue, but problems that
    > have nothing to do with concurrency and data races.


    Classloaders define a sort of namespace wherein the "same" class from
    two different classloaders is actually two different classes. Like so
    much in Java, this is a very powerful technique that can mess you up a
    lot if you're careless or don't fully grasp the consequences.

    Classloader magic is one of those "here there be dragons" regions of
    Java. I've dabbled in it, but I am Dukas' Sorcerers Apprentice when
    it comes to their use.

    --
    Lew
     
    lewbloch, Jul 27, 2011
    #5
  6. Ross

    Alice Guest

    On 27/07/2011 5:06 PM, lewbloch wrote:
    > Henderson wrote:
    >> The main concern, instead, is invariant violation when the design
    >> expects a singleton of some sort: a single global registry of some sort,
    >> a single global interning cache, a single INSTANCE reference to a single
    >> singleton instance such as what java.awt.Toolkit.getDefaultToolkit()
    >> returns, etc.; if there are suddenly two of a thing like that when the
    >> design calls for exactly one, then problems can ensue, but problems that
    >> have nothing to do with concurrency and data races.

    >
    > Classloaders define a sort of namespace wherein the "same" class from
    > two different classloaders is actually two different classes. Like so
    > much in Java, this is a very powerful technique that can mess you up a
    > lot if you're careless or don't fully grasp the consequences.


    Classic pontification.

    > Classloader magic is one of those "here there be dragons" regions of
    > Java. I've dabbled in it, but I am Dukas' Sorcerers Apprentice when
    > it comes to their use.


    Classic pontification.
     
    Alice, Jul 28, 2011
    #6
  7. Ross

    Ross Guest

    Thanks. The program just uses the standard ClassLoader, and doesn't
    even have that many classes.

    In the static synchronized method, a password file is being rewritten.
    If this program gets adopted long term, I'll be rewriting it to use a
    proper database, and data synchronisation issues will disappear. But
    "static synchronized" will do for the meantime.
     
    Ross, Jul 28, 2011
    #7
  8. Ross

    lewbloch Guest

    On Jul 27, 7:04 pm, Alice <> wrote:
    > On 27/07/2011 5:06 PM, lewbloch wrote:
    >
    > > Henderson wrote:
    > >> The main concern, instead, is invariant violation when the design
    > >> expects a singleton of some sort: a single global registry of some sort,
    > >> a single global interning cache, a single INSTANCE reference to a single
    > >> singleton instance such as what java.awt.Toolkit.getDefaultToolkit()
    > >> returns, etc.; if there are suddenly two of a thing like that when the
    > >> design calls for exactly one, then problems can ensue, but problems that
    > >> have nothing to do with concurrency and data races.

    >
    > > Classloaders define a sort of namespace wherein the "same" class from
    > > two different classloaders is actually two different classes.  Like so
    > > much in Java, this is a very powerful technique that can mess you up a
    > > lot if you're careless or don't fully grasp the consequences.

    >
    > Classic pontification.
    >
    > > Classloader magic is one of those "here there be dragons" regions of
    > > Java.  I've dabbled in it, but I am Dukas' Sorcerers Apprentice when
    > > it comes to their use.

    >
    > Classic pontification.


    Troll. Plonk.

    --
    Lew
     
    lewbloch, Jul 29, 2011
    #8
  9. Ross

    lewbloch Guest

    On Jul 28, 3:09 am, Ross <> wrote:
    > Thanks. The program just uses the standard ClassLoader, and doesn't
    > even have that many classes.
    >
    > In the static synchronized method, a password file is being rewritten.
    > If this program gets adopted long term, I'll be rewriting it to use a
    > proper database, and data synchronisation issues will disappear. But
    > "static synchronized" will do for the meantime.


    Why do you want the method to be static?

    It's not wrong, but an instance method would also work. I'm
    interested in the reasoning.

    --
    Lew
     
    lewbloch, Jul 29, 2011
    #9
  10. Ross

    Alice Guest

    On 29/07/2011 12:28 PM, lewbloch wrote:
    > On Jul 27, 7:04 pm, Alice<> wrote:
    >> On 27/07/2011 5:06 PM, lewbloch wrote:
    >>> Classloader magic is one of those "here there be dragons" regions of
    >>> Java. I've dabbled in it, but I am Dukas' Sorcerers Apprentice when
    >>> it comes to their use.

    >>
    >> Classic pontification.

    >
    > Troll.


    What does your trolling have to do with Java, lewbloch?

    > Plonk.


    Famous last word.
     
    Alice, Jul 29, 2011
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jerry
    Replies:
    4
    Views:
    132,040
    tonni
    Aug 11, 2010
  2. Pep
    Replies:
    6
    Views:
    29,364
  3. Knute Johnson

    synchronized static methods?

    Knute Johnson, Mar 6, 2006, in forum: Java
    Replies:
    5
    Views:
    20,745
    Knute Johnson
    Mar 7, 2006
  4. dmcreyno
    Replies:
    9
    Views:
    9,623
    Mark Space
    Jun 27, 2006
  5. ankur
    Replies:
    4
    Views:
    1,506
    Eric Sosman
    Nov 28, 2008
Loading...

Share This Page