> On Nov 25, 2014, at 20:55, Tom Hawtin <tom.haw...@oracle.com> wrote:
>
>
>
> 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.
This sounds reasonable. Otherwise I cannot imagine why the calculation needs be
taken out of URL class.
> 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.
Shall we encapsulate all of these in a new java.net.Host class?
--Max
>
> Tom
