On 8/30/2010 9:18 PM, Caldarale, Charles R wrote:
There's a lot of baggage implemented to support ThreadLocal. It's one of those deceptively easy-to-use Java concepts that utilizes a lot of plumbing underneath the covers (e.g., a specialized per-thread expandable hash map, weak references). The basic implementation is that of a hash map per thread, using the ThreadLocal object as the key, and the reference from the argument to ThreadLocal.set() as the value. There's no actual requirement that the values are in fact thread-local, but they usually are so that synchronization can be avoided.
There needs to be a balance between caching/pooling and abuse of memory. Caching/pooling needs to be worth the trouble of doing it and the memory it takes up. For example in iCal4j with SimpleDateFormat, I don't really see why it's so important to have it static. It seems to me that using static ThreadLocal's isn't going to save that much overhead vs. just creating a regular local object each time you run. It seems to me that things like that should be reserved for something that's more expensive to create, like something that requires doing I/O. A SimpleDateFormat doesn't require any I/O to be created. Its format string might come from a ResourceBundle but I believe those only do I/O the first time they are loaded. I do some static caching in my app but it's of data pulled from a database on another host, making it expensive to create. It's also data that gets used frequently but changes rarely. Synchronization around a HashMap or Hashtable is cheaper than hitting the database. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
