是否值得清除Filter中的ThreadLocals以解决与线程池相关的问题?

Boz*_*zho 14 java multithreading tomcat servlets

简而言之 - tomcat使用线程池,因此可以重用线程.有些库使用ThreadLocal变量,但不清理它们(使用.remove()),所以实际上它们会将"脏"线程返回到池中.

Tomcat具有在关闭时检测这些内容以及清理线程本地的新功能.但这意味着线程在整个执行过程中都是"脏"的.

我能做的是实现a Filter,并在请求完成后(并将线程返回到池中)ThreadLocal,使用tomcat中代码(调用的方法)清除所有s checkThreadLocalsForLeaks.

问题是,值得吗?两个优点:

  • 防止内存泄漏
  • 防止库的不确定行为,假设线程是"新鲜的"

一个骗局:

  • 该解决方案使用反射,因此它可能很慢.Field当然,所有反射数据都将被缓存,但仍然如此.

另一种选择是将问题报告给不清除其线程本地的库.

Aug*_*sto 6

我会通过以下两个原因通过向图书馆开发人员报告问题的途径:

  • 它将有助于其他想要使用相同库的人,但缺乏技能/时间来找到这样一个可怕的内存泄漏.
  • 帮助库的开发人员构建更好的产品.

老实说,我之前从未见过这种类型的错误,我认为这是一个例外,而不是我们应该保护的事情,因为它经常发生.你能分享一下你见过这种行为的图书馆吗?

作为旁注,我不介意在开发/测试环境中启用该过滤器,并在仍附加ThreadLocal变量时记录严重错误.