URLStreamHandler.getHostAddress() performance
Tom Hawtin
tom.hawtin at oracle.com
Tue Nov 25 17:42:52 UTC 2014
On 25/11/2014 14:13, Wang Weijun wrote:
>> 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?
I meant the general algorithm for locking based on a value. Though a
quick look through the JDK source doesn't turn up much.
Looking at it a bit further, it may make sense to push the logic to
avoid parallel identical DNS lookups down to at least
InetAddress.getAllByName0. A "value-based" lock around the call to
getAddressesFromNameService but not getCachedAddresses. This way, large
numbers of identical, already-cached lookups could have minimal
interference with each other. The Cache implementation is a bit old
school, though probably sufficient.
If you have large numbers of simultaneous lookups, I guess they're
probably all of the same thing. Many class files loaded from the same
host, for example. So switching from an effectively global lock to a
lock based on hostname value is unlikely to help performance.
Tom
More information about the security-dev
mailing list