I need some clarification on threading issues. I have been programming in Java for several years so I have a good background. I created a utility package at our company. Some of the classes in this package were designed to be convenience classes. This means that the methods in these classes were defined as static so that when these convenience methods were used, the caller could simply call class.staticMethodName(). I am now realizing that this may be a threading issue. Specifically, I have a DateFormatter class that allows the caller to format a GregorianCalendar in several different date formats. The date formats are static SimpleDateFormats defined in this class that are then used in the appropriate static methods. After a difficult time of tracking down the problem, I found out that the reason the GregorianCalendar was being formatted as 0012/0020/1986 when the date was supposed to be 12/20/2003 was due to threading problems in the DateFormatter class. I believe that if I make these static methods synchronized, the problem should disappear. However, I have some confusion on this. When do I need to be concerned with threading? Do all static methods need to be synchronized? Or if I move the declaration of the SimpleDateFormat instance to within the static method instead of a static class instance will this then be thread-safe? Furthermore, other classes in the utility package are meant to be base classes that are extended in application specific packages. For example, there is a Person class containing first/middle/last names, etc that is then extended. There are no static variables or methods in these classes. Therefore, I believe that these classes are thread-safe. Is this correct? I haven't dealt a lot with threading issues and am now concerned that I need to change my implementation. One of my concerns with adding the keyword "synchronized" to methods, as I've read that it can affect performance. Your comments are appreciated.
Is your code actually creating any threads? I know that when the jvm runs it does it in a multithreaded fashion, but does your code expectly create any threads? Because if it doesn't than you don't need to worry about "synchronization". As a side note why would you define a method as static? Defining a method as static means you only want one copy of that method. So evey piece of code which calls that method is using the same code. Sharing the variables if I am not mistaken. "static" is not good OO.
Please ignore post, I have no idea what I am talking about.
Is your code actually creating any threads? I know that when the jvm runs it does it in a multithreaded fashion, but does your code expectly create any threads? Because if it doesn't than you don't need to worry about "synchronization".
I am not explicitly creating any threads. I guess Java is making doing it when the code is executed. However, my contact at IBM says that the reason my dates are displayed incorrectly is because of threads.
As a side note why would you define a method as static? Defining a method as static means you only want one copy of that method. So evey piece of code which calls that method is using the same code. Sharing the variables if I am not mistaken. "static" is not good OO.
I created the convenience methods in some classes in my utility package as static so that they could be easily accessed in JSP's by calling classname.methodName() without having to instantiate the class. If this is not good OO, what is the recommended way to have convenience methods? How should they be implemented? I am very interested in improving my code. Please continue to comment.
I created the convenience methods in some classes in my utility package as static so that they could be easily accessed in JSP's by calling classname.methodName() without having to instantiate the class.
So do you understand now why this is a problem? You have more than one program using a static method. Making the method static gives you only one copy of it. So everyone one calling that method is using the same code. And there is a good chance that this code is being used by more than one JSP at the same time. One solution is to give everyone their own copy of this method. Which means it can't be static. Which sounds like you need to redesign things. Anther solution is to use "synchonize" as you stated earlier, and yes this can slow you down as only one JSP will be allowed to use this method at a time. But depending on how frequently the method is being called it may not slow you down.
I don't think the code inside the method will give you any trouble, even if called by many threads. Each thread executes with its own stack and any local variables are allocated there, nicely separated from the other threads. But if the code references anything outside the method you are immediately at risk. If you set a member variable on one line and read it on the next, another thread could sneak in and change it while you are between lines. If you can avoid modifying anything oustide the method you will probably be just fine. If you must, then you'll want to synchronize (force sequential access to) that resource. And you'll want to go get that book on threading.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 18, 2001
But if the code references anything outside the method you are immediately at risk.
What if the something outside the method is a public static final String (a constant)? Isn't this immutable and therefore safe? Furthermore, can anyone comment on the most appropriate way in which to have convenience methods to be used by many different apps? Are static methods not a good idea even when they only use local variables? What is the recommended way to have a standard method to format GregorianCalendars as MM/dd/yyyy? Thanks again for your comments.
Originally posted by verduka fox: The date formats are static SimpleDateFormats defined in this class that are then used in the appropriate static methods.
It sounds as though these are the problem. If, instead of having static SimpleDateFormats in the class you have them as local variables, you should not have a problem. As mentioned above, they would each be then created in their own thread. Since they are static members of the class, they are being manipulated by multiple threads at the same time. Your format Strings could be static final Strings, but the actual DateFormats would be created using these strings, used to format, and then conceptually destroyed when the method exits.
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joined: Jan 18, 2001
Ok, I think I now understand. If I have a convenience class in which the methods are static for formatting dates, the SimpleDateFormat instance should be instantiated within the method. The string that defines the format can be a constant (public static final String), but the SimpleDateFormat must not be. What about the comment that static is not good OO? What is the recommended way of having a utility to perform common functions? Furthermore, do I need to worry about synchronization when I have classes that are later extended? For example, if I have class A that is included in the utility package, and class B in my project package extends class A, do I need to add synchronized to these methods? Both class A and class B have class variables that are accessed by each instance of the class. Does synchronization become an issue with different instances of the same class, or only when different objects are accessing the same instance? Thanks again for the comments. I really appreciate your insight.
Does synchronization become an issue with different instances of the same class
Synchronization becomes an issue with different instances of the same class only when you use static variables.
Joined: Jan 29, 2003
I have no problem with static methods. For example I have a string utility with many static methods. Is that "good OO"? Some might say no, but my take is: Objects encapsulate state and behavior. If there is no state, it's more of collection of functions than an object, and static methods are fine. I also use static methods to shorten up utility code:
A common problem with such utilities is: If you want an instance, where can you get it? A common answer shown above is make it a factory for itself that returns a singleton, but that's just a global which is arguably worse OO than the static method ever was.