On 25/11/2014 12:02, Wang Weijun wrote:
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress(URL u) {
[...]
Is there any reason why the method is synchronized? Why not simply "synchronized
(u)"?
Synchronizing on a public object is usually a bad idea. For instance
Thread.join has had some interesting interactions with non-Java library
code, and AFAIK that wasn't sprung in an update.
If the address resolution is not pinned, then unsynchonised access could
result in the hostAddress changing, which is bad. However, it seems the
major useful effect is to stop a large number of parallel DNS lookups
for the same address. Neither InetAddress nor DNSNameService does not
appear to do that itself, though I've not looked deeply into the mechanism.
So, I would suggest a lock/compare-and-set for just the write to the
previously null URL.hostAddress, and locking based on the value of
URL.getHost (don't synchronise on String (that'd be a little like
synchronising on URL!)!). There's probably several places in the Java
library doing something similar with Maps and Futures.
Tom
