Skip to main content

Add static variable in method body

6 replies [Last post]
wangzaixiang
Offline
Joined: 2004-11-24

Java's method can declare only local stack based varible, which is live only during a call. C method is something like it, but it support a "static" declare which makes the variable long lived between method call.

In java, because there is no "static" usage, so we need to put the variable as a "instance" field, although it works, but it smells worse in most cases. by using the "static" declare, we know only the method will using the variable, and it is not share for other methods, but instance varible shares for the all methods in the same class.

eg, a method may allocate 2K buffer for its process, since the method will calls frequently, to avoid allocate the space each time, we may make it as an instance varible, but it will make the class looks worse. instead, if we declare it as the method's "static" varible, it will be more clear.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
wangzaixiang
Offline
Joined: 2004-11-24

the ThreadLocal provide a different functions than "static" variable, the "static" is just a compiler cookie that makes a instance variable visible for a given method and not for others.

tackline
Offline
Joined: 2003-06-19

The point is that you can have a ThreadLocal in a static final variable, and its value acts like a good old fashioned single-threaded C static. As in:

private static final ThreadLocal buffs =
new ThreadLocal() {
protected byte[] initialValue() {
return new byte[8192];
}
}
}
/** Safe for multiple threads to invoke simultaneously. */
public static void copy(InputStream in, OutputStream out) {
byte[] buff = buffs.get();
...

}

tackline
Offline
Joined: 2003-06-19

A buffer probably isn't a good example. It's not going to be thread safe if you share naively.

And why shouldn't more than one method require a buffer? It seems marginal to have a static (final) declared within a method body instead of just outside.

What could be useful, IMO, is a 'once' expression that evaluates only once. For instance, to compile a regular expression, or similar with other minilanguages.

wangzaixiang
Offline
Joined: 2004-11-24

the "static" usage inside C method is only a compiler support cookie which makes the source code much clearly. and it is something widely used in C code because it is usefull.

Why shouldnt more than one method require a buff? if so, i think it is good to declare it as instance level field, because it is shared between multi method, all these method share the contract to use it. but if there is only a method take care of it, declare it locally to the method is more clearly. that is "static" done.

really, such a method maybe thread unsafe, but if you use instance varible, it maybe unsafe also.

forax
Offline
Joined: 2004-10-07

> the "static" usage inside C method is only a compiler
> support cookie which makes the source code much
> clearly. and it is something widely used in C code
> because it is usefull.
>
> Why shouldnt more than one method require a buff? if
> so, i think it is good to declare it as instance
> level field, because it is shared between multi
> method, all these method share the contract to use
> it. but if there is only a method take care of it,
> declare it locally to the method is more clearly.
> that is "static" done.
>
> really, such a method maybe thread unsafe, but if you
> use instance varible, it maybe unsafe also.

look java.lang.ThreadLocal and InheritedThreadLocal,
it's a re-entrant way to implements the local
'static' as in C.

tackline
Offline
Joined: 2003-06-19

> > the "static" usage inside C method is only a
> compiler
> > support cookie which makes the source code much
> > clearly. and it is something widely used in C code
> > because it is usefull.

I wasn't aware that it was popular in C. I understand that there are initialisation order issues when using it in C++.

> > really, such a method maybe thread unsafe, but if
> you
> > use instance varible, it maybe unsafe also.

True, but I'd suggest being very careful about such optimisations in any case. If you try synchronising for a static variable you are more likely to hit scalability issues than for an instance variable.

> look java.lang.ThreadLocal and InheritedThreadLocal,
> it's a re-entrant way to implements the local
> 'static' as in C.

ThreadLocal and InheritableThreadLocal can be useful for certain forms of caching. Although funnily enough, they are not re-entrant themselves (yet).