ThreadLocal和非线程安全的API

Question

所以我有一个非线程安全的API(一些供应商软件),我正在使用它,我们当前使用它的方式是每个线程一个对象.即每个线程都有:

Foo instance = new Foo();

但是,这似乎不适用于此特定库.它的一些非线程安全位仍然看起来像是头,所以我假设这个库里面有一些静态值.在我们知道它有问题的几个点上,我们目前正在使用ReentrantLock在需要时锁定该类.IE

public class Bar {
    protected static final ReentrantLock lock = new ReentrantLock();

    public void process() {
        Foo instance = new Foo();
        boolean locked = false;
        try{
            if(SomeCondition) {
                locked = true;
                Bar.lock.lock();
            }

            *//rest of the processing goes here

        } finally {
            if(locked){
                Bar.lock.unlock();
            }
        }
    }
}

我的问题是:在这样一个实例中,所讨论的类不是线程安全的,即使在创建所述类的新实例时,使用锁定是否更好,或者我应该看看我是否正在使用ThreadLocals？ThreadLocals会减轻我的实际问题吗？类的ThreadLocal版本是否实际上强制类的静态区域基本上是非静态的？

Answer 1

所有ThreadLocal都会创建一个查找,其中每个线程都可以找到自己的对象实例,因此没有线程必须共享.从概念上讲,您可以将其视为由线程ID键入的映射.

在某些情况下,让每个线程使用自己的对象是一个很好的策略,它在JCIP书中被称为"线程限制".一个常见的例子是SimpleDateFormat对象不是设计为线程安全的,并且使用它们的并发线程产生了错误的结果.使用ThreadLocal允许每个线程使用自己的DateFormat,请参阅此问题以获取示例.

但是如果您的问题是对象引用了静态字段,那么这些静态字段存在于类中,而不存在于实例上,因此使用ThreadLocal不会做任何事情来减少共享.

如果你的每个线程都以某种方式使用它自己的类加载器,那么每个线程都有自己的类,并且不会共享它上面的静态字段.否则你对类的锁定似乎是合理的(尽管考虑到所有的线程都会争用同一个锁,但可能并不快).最好的方法是与供应商合作,让他们修复破损的代码.