Ever a reason to not call notify()?

Question

within a sychronized block, is there ever a reason to not call notify(); just before exiting?
specifically, i'm sharing a collection across multiple thread classes.
(1) if i know that no thread will ever wait() on the collection, i never need to invoke notify().
(2) yet, is there ever any downside to always invoking notify();
in the future, it might happen that some object will wait() on the shared collection. and due to
encapsulation of the source, the new developer will not see this, or do anything about it.
so, just to be safe, shouldn't i always call notify(). ?
other minor issue:
(1) when possible shouldn't i use notify() instead of notifyAll() ?
if all waiting threads awaken, then there must be some overhead involved for
resolving which of the competing objects will get the lock?

Answer 1

ropp wrote:
in the future, it might happen that some object will wait() on the shared collection. and due to
encapsulation of the source, the new developer will not see this, or do anything about it.
so, just to be safe, shouldn't i always call notify(). ?Then you have a much bigger issue at hand. Specifically, you are creating a shared API where usage of that API is completely dependent on some unexposed internals of that API. I'd say you should instead design your shared points so this isn't an issue.