File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark ""static" and threads explanation?" Watch ""static" and threads explanation?" New topic

"static" and threads explanation?

Tommy Sedin

Joined: Jan 04, 2003
Posts: 2
I hope this question landed in the right part of this forum.
I've read on a few sites that you should always try to avoid declaring methods and/or variables as static when several threads will try to access them (I think the actual words were "avoid static like the plague"). Now, I understand what happens when you declare a method or variable as static, but I'm not sure exactly how it affects threading.
I'm guessing that you cannot call static methods simultaneously, but reading static variables in non-static methods should have no such limitation.
That would explain the use of "factory methods" that I see a little here and there..
So the question is basically: How does declaring methods and variables as static affect Java's ability to access these methods and variables from different threads simultaneously?
Thanks for any help
Tommy Sedin
boyet silverio
Ranch Hand

Joined: Aug 28, 2002
Posts: 173
Just imagine, that in a video-music bar, a mike (microphone) while being used (threading/processing) by a customer is suddenly held also by another who had too much to drink during the new year's party and started garbling a different tune (thread/process) at the same time. It would probably be bedlam if the current holder refuses to give in! This situation could arise if the mike is "static", that is, the mike could just be used by any customer anytime.
public class Customer{
static String mike;
public void setSong(String song)
{ mike = song; }
public String getSong()
{ return mike; }
say, in the video bar, customer # 1 merrily sings "Jingle bells! Jingle bells!" (in thread 1)
i.e. customer1.setSong("Jingle bells! Jingle bells! Jingle all the way! ...");

then another customer (#2) joins in and simultaneously sings (in thread 2)
i.e. customer2.setSong("We will, we will rock you! chug-chug-chug, chug-chug-chug! ...");
when customer # 1 tries to listen to the speaker boxes,
i.e. customer1.getSong();
instead of hearing his voice, he might be hearing the angry voice of customer # 2's ... "we will we will rock you....."
i.e. return mike
n.b. thread ~ process
I hope this helps, in a way.
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Calling a static method from different threads is similar to calling a non-static method on the same object from different threads. As long is it does only work on local variables, it can't do any harm at all - and if it does work on fields, you'd need to think about synchronization, anyway.
So I don't see how wether to make a method static should be influenced by threading issues.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Well, if you're calling a static method in a multithreaded environment, there's a good chance the method is synchronized. This means that all threads will be synchronizing using the same monitor - namely the Class object representing the class in which the static method is defined. This may well create a single choke point in the application, as each thread has to wait for access to that monitor before it can proceed. If the method is nonstatic rather than static, then there's a greater chance that different thread will be attempting to synchronize on different monitors, and thus will not compete directly for locks. But this really depends on how you distribute and use the objects containing synchronized methods - it's difficult to make many general statements here.

"I'm not back." - Bill Harding, Twister
I agree. Here's the link:
subject: "static" and threads explanation?
It's not a secret anymore!