Thread Safety

Thread safety is under specified, in particular: Here are some tips about thread safety. In the Sun VM, there is a garbage collection thread that is responsible for freeing un-referenced objects and calling their finalizers. If your finalizer calls synchronized methods, you can wind up with very hard to debug deadlocks.

A rule of thumb is: never assume that JDK objects are thread safe. Do not think, "Oh, I bet I can guess the implementation, and it must be thread safe." For example, java.util.SimpleDateFormat is not thread safe, so things like this will cause strange formatting errors in multithreaded programs. Swing components are not thread-safe. You must use javax.swing.SwingUtilities.invokeLater()/invokeAndWait() in any code which might possibly be called by a thread other than the main event-dispatching thread. This crops up frequently in writing custom ListModels and TreeModels which respond to non-local or non-GUI events.

java.util.Hashtable and java.util.Vector are two examples of JDK objects whose every method is synchronized. This imposes a large runtime cost on applications that iterate over these structures. When you are not using threads, prefer java.util.HashMap and java.util.ArrayList. Thread.sleep(5000) is supposed to sleep for 5 seconds. However, if somebody changes the system time, you may sleep for a very long time or no time at all. The OS records the wake up time in absolute form, not relative.

Thread scheduling is not guaranteed to be round-robin. A task may totally hog the cpu at the expense of threads of the same priority. You can use Thread.yield() to have a conscience. You can use Thread.setPriority(Thread.NORM_PRIORITY-1) to lower a thread's priority. In Applets you need security clearance to even lower thread priority.

FAQ Home

 

Advertisement

Free Magazine