Develop Reference

Why wait, notify and notifyAll are methods in Object class not like Cloneable

Recently, I was asked in interview why wait, notify, and notifyAll are used. I explained them.
After that they asked me to assume an application is always single threaded. Is it really required? My answer was no.
Then, they asked why is design like wait, notify, and notifyAll are methods on the Object class. Why doesn't Java have an interface and these methods are in that interface and which ever class wants to implement it can use it. So, I was kind of stuck and unable to think over this design. Can anyone please sow light over this?

JVM uses OS-level threads. That means that each concrete JVM for each concrete OS handles threads differently. And these methods are not only implemented in Object class, they are marked as native, which kind of means that the are implemented in system layer of JVM.
And if those methods were in some interface, that would mean that anybody can redefine them.

Wait and notify and notifyAll is not just normal methods or synchronization utility, more than that they are communication mechanism between two threads in Java. And Object class is correct place to make them available for every object if this mechanism is not available via any java keyword like synchronized. Remember synchronized and wait notify are two different area and don’t confuse that they are same or related. Synchronized is to provide mutual exclusion and ensuring thread safety of Java class like race condition while wait and notify are communication mechanism between two thread.

Then, they asked why is design like wait, notify, and notifyAll are methods on the Object class. Why doesn't Java have an interface and these methods are in that interface and which ever class wants to implement it can use it.
All of these methods are implemented in native code and they integrate closely with the synchronized block that wraps them. They are part of the Java language definition and have specific behaviors that programmers rely on. It would not be appropriate for them just to be interface methods that any object would implement.
When one object calls obj.wait(); on another object, it doesn't have to worry about the implementation of wait. It needs to make sure that it has a mutex lock on that object so it can make critical updates to it or other storage and if the wait method was implemented by the object itself, then that object could violate the language requirements and, for example, allow multiple threads into the protected block at the same time. A thread can synchronize and call wait/notify/notifyAll on another object or not without having to worry about whether or not that object has implemented those methods appropriately. By making them final methods on Object the behavior will work the same regardless of the object type or local implementation.
Also, as I mentioned, wait/notify/notifyAll are integrated closely with the surrounding synchronized block. When a thread is blocked in wait() the surrounding synchronized lock is released so that other threads can get access to the protected block. This coordination would not be possible if the wait() was just a simple method call without other strange language features.
This reminds me of my other answer here: Concept behind putting wait(),notify() methods in Object class

It was a design goal from the start that Java programs would be multithreaded. Remember the plan was for Java to make embedded programming less intimidating, the whole serverside web application thing (leading to the commoditization of Sun's core business) was an accident.
Since the goal was to enable creating embedded applications that would talk to other devices, it had to be multithreaded in order to be network-friendly and event-driven. But writing efficient multithreaded servers wasn't high on the list for java.
Java didn't have ReentrantLock or nonblocking i/o for a long time. Initially the main data structures available were Vector, Hashtable, and StringBuffer (all of which had synchronized on all public methods). From that choice it seems like the goal was good-enough, as opposed to being as efficient as possible. Later on it was clear Java needed to be more efficient for the use case of server applications and 1.2 introduced equivalents of Vector and Hashtable that were unsynchronized. This seemed like an afterthought, a course adjustment made once it was apparent Java had a new role it wasn't previously designed for.
If Java had stayed in the niche it was created for then possibly intrinsic locks might have been adequate. It seems the initial plan was for intrinsic locks only, so that the lock might as well be wired into the Object.

Synchronization, When to or not to use?

I have started learning concurrency and threads in Java. I know the basics of synchronized (i.e. what it does). Conceptually I understand that it provides mutually exclusive access to a shared resource with multiple threads in Java. But when faced with an example like the one below I am confused about whether it is a good idea to have it synchronized. I know that critical sections of the code should be synchronized and this keyword should not be overused or it effects the performance.
public static synchronized List<AClass> sortA(AClass[] aArray)
{
List<AClass> aObj = getList(aArray);
Collections.sort(aObj, new AComparator());
return aObj;
}
public static synchronized List<AClass> getList(AClass[] anArray)
{
//It converts an array to a list and returns
}

Assuming each thread passes a different array then no synchronization is needed, because the rest of the variables are local.
If instead you fire off a few threads all calling sortA and passing a reference to the same array, you'd be in trouble without synchronized, because they would interfere with eachother.
Beware, that it would seem from the example that the getList method returns a new List from an array, such that even if the threads pass the same array, you get different List objects. This is misleading. For example, using Arrays.asList creates a List backed by the given array, but the javadoc clearly states that Changes to the returned list "write through" to the array. so be careful about this.

Synchronization is usually needed when you are sharing data between multiple invocations and there is a possibility that the data would be modified resulting in inconsistency. If the data is read-only then you dont need to synchronize.
In the code snippet above, there is no data that is being shared. The methods work on the input provided and return the output. If multiple threads invoke one of your method, each invocation will have its own input and output. Hence, there is no chance of in-consistency anywhere. So, your methods in the above snippet need not be synchornized.
Synchronisation, if unnecessarily used, would sure degrade the performance due to the overheads involved and hence should be cautiously used only when required.

Your static methods don't depend on any shared state, so need not be synchronized.

There is no rule defined like when to use synchronized and when not, when you are sure that your code will not be accessed by concurrent threads then you can avoid using synchronised.

Synchronization as you have correctly figured has an impact on the throughput of your application, and can also lead to starving thread.
All get basically should be non blocking as Collections under concurrency package have implemented.
As in your example all calling thread will pass there own copy of array, getList doesn't need to be synchronized so is sortA method as all other variables are local.
Local variables live on stack and every thread has its own stack so other threads cannot interfere with it.
You need synchronization when you change the state of the Object that other threads should see in an consistent state, if your calls don't change the state of the object you don't need synchronization.

I wouldn't use synchronized on single threaded code. i.e. where there is no chance an object will be accessed by multiple threads.
This may appear obvious but ~99% of StringBuffer used in the JDK can only be used by one thread can be replaced with a StringBuilder (which is not synchronized)

Making a scheduled method Thread safe

I have a method that is invoked by a scheduler every minute to get a file from ftp, process and persists its records to a DB. I need to make this thread safe so that if the method has to perform multiple files at once, it acts a in a thread safe way..
public synchronized void processData(String data){
//do processing
}
is this really going to be a thread safe method that will handle high volumes of load gracefully?

It's thread-safe as long as it doesn't use any stateful fields from the enclosing object.
In other words, if there is a class-level field that is manipulated or accessed in processData(String data) with the intention of keeping track of what's going on, then it's not thread-safe.
An example might be a class-level field called private Boolean hasConnection; If you need to check whether or not a connection exists with this field, then you don't have a thread-safe method.
If you meet this requirement, then you don't even have to add the synchronized keyword to your method. It will be, by default, thread-safe, and an unlimited number of threads may access it simultaneously.
If you do not meet this requirement, then you will need to post the whole class in order to determine whether or not it is thread-safe.

Assuming that the mysterious "process the file" operation is self-contained, the biggest thing you should worry about is your DB connection: do not make it shared, obtain a new one each time from a connection string, and use a connection pool. Do not make your method synchronized, unless you need to access shared state inside your class; otherwise, your method would not be able to make progress concurrently on multiple threads.

Please describe us what resources your method uses, and which of those resources are shared.
If you do not use common object, there is no problem.
If you do use common resources, you need to make sure these resources can be accessed in a thread-safe manner, or are not accessed by multiple threads.
Your question is about performance. In general, processData seems to be a method which will take some time to complete: you are using databases. The time required to get a lock is minimal compared to a DB Query. So no, the synchronized keyword will not give you any noticeable performance impact.

using static classes in servlets

Servlets are not thread safe. So if I use a static function of a class, What will happen when multiple requests come at the same time. How will they deal with the static function?

You'll have to synchronize it if accesses shared, mutable data. If the data is immutable or read-only or on the stack you should be fine.

It depends on what kind of static method do you have whether it is stateless or not. If it is stateless, and not referencing anything outside from your method's scope it will be thread safe.

if you are using static method in servlets you need to make them thread safe by
Using only local variables when state of the variable may change
or use static variable if they dont change or use synchronize access method
and you can amke function thread safe by implementing the SingleThreadModle interface or by 'synchronize' construct.

Is java.lang.reflect.Method thread safe?

Is java.lang.reflect.Method thread safe?
Profiling result of my program showed that Class.getMethod() took considerable computing time when called many times, a little more than I expected.
I can call this once and store the resulting method somewhere easily accessible.
But then, multiple web worker threads will use the stored Method object concurrently.
Is this safe?

The Method is safe to use accross multiple threads provided you don't change the Method's state after making it available to multiple threads.e.g. You can call setAccessible(true) and setAccessible(false) in two threads and the result would be not thread safe. However this has no really good use.
In short, Method.setAccessible() is not techincally thread safe, but you should be able to use it in a thread safe way.

Java classes are guaranteed to be defined only once per ClassLoader instance, so you can safely assume that the definition, including methods and their signatures will not change through time, so you can safely "cache" them for use by multiple threads.
However, keep in mind that classes with the same fully qualified name (package + class name) can be defined differently by separate ClassLoader instances.

The class definition isn't going to change, so unless you are loading different classes in different threads (from separate libraries, say), the Method object should be thread safe. (Of course, whether the method itself being called by reflection is thread-safe is a different question.)