线程安全

通过这篇博客你能学到什么:

编写线程安全的代码,本质上就管理状态的访问,而且通常是共享的、可变的状态.

状态:可以理解为对象的成员变量.

共享: 是指一个变量可以被多个线程访问

可变: 是指变量的值在生命周期内可以改变.

保证线程安全就是要在不可控制的并发访问中保护数据.

如果对象在多线程环境下无法保证线程安全,就会导致脏数据和其它不可预期的后果

在多线程编程中有一个原则:
无论何时,只要有对于一个的线程访问给定的状态变量,而且其中某个线程会修改该变量,此时必须使用同步来协调线程对该变量的访问

Java中使用synchronized(同步)来确保线程安全.在synchronized(同步)块中的代码,可以保证在多线程环境下的原子性(操作原子的执行)和可见性(不会有过期数据).

不要忽略同步的重要性,如果程序中忽略了必要的同步,可能看上去是可以运行,但是它仍然存在隐患,随时都可能崩溃.

在没有正确同步的情况下,如果多线程访问了同一变量(并且有线程会修改变量,如果是只读,它还是线程安全的),你的程序就存在隐患,有三种方法修复它:
1. 不要跨线程共享变量
2. 使状态变为不可变的
3. 在任何访问状态变量的时候使用同步

虽然可以用上述三类方法进行修改,但是会很麻烦、困难,所以一开始就将一个类设计成是线程安全的,比在后期重新修复它更容易

封装可以帮助你构建线程安全你的类,访问特定变量(状态)的代码越少,越容易确保使用恰当的同步,也越容易推断出访问一个变量所需的条件.总之,对程序的状态封装得越好,你的程序就越容易实现线程安全,同时有助于维护者保持这种线程安全性.

设计线程安全的类时,优秀的面向技术--封装、不可变性(final修饰的)以及明确的不变约束(可以理解为if-else)会给你提供诸多的帮助

虽然程序的响应速度很重要,但是正确性才是摆在首位的,你的程序跑的再快,结果是错的也没有任何意义,所以要先保证正确性然后再尝试去优化,这是一个很好的开发原则.

1.线程安全性

一个类是线程安全的,是指在被多个线程访问时,类可以持续进行正确的行为.

2 一个无状态的(stateless)的servlet

public class StatelessServlet implements Servlet {

@Override
public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
BigInteger i = extractFromRequest(servletRequest);
BigInteger[] factors = factor(i);
encodeIntoResponse(servletResponse,factors);
}

}

我们自定义的StatelessServlet是无状态对象(没有成员变量保存数据),在方法体内声明的变量i和factors是本地变量,只有进入到这个方法的执行线程才能访问,变量在其他线程中不是共享的,线程访问无状态对象的方法,不会影响到其他线程访问该对象时的正确性,所以无状态对象是线程安全的.

这里有重要的概念要记好:无状态(成员变量)对象永远是线程安全的

3 原子性

在无状态对象中,加入一个状态元素,用来计数,在每次访问对象的方法时执行行自增操作.

public class StatelessServlet implements Servlet {
private long count = 0;

@Override
public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
BigInteger i = extractFromRequest(servletRequest);
BigInteger[] factors = factor(i);
count++;
encodeIntoResponse(servletResponse,factors);
}

在单线程的环境下运行很perfect,但是在多线程环境下它并不是线程安全的.为什么呢? 因为count++;并不是原子操作,它是由"读-改-写"三个操作组成的,读取count的值,+1,写入count的值,我们来想象一下,有两个线程同一时刻都执行到count++这一行,同时读取到一个数字比如9,都加1,都写入10,嗯平白无故少了一计数.

现在我们明白了为什么自增操作不是线程安全的,现在我们来引入一个名词竞争条件.

4 竞争条件

当计算的正确性依赖于运行时相关的时序或者多线程的交替时,会产生竞争条件.

除了上面的自增,还有一种常见的竞争条件--"检查再运行".

废话不多说,上代码.

/**
 * @author liuboren
 * @Title: RaceCondition
 * @ProjectName multithreading
 * @Description: TODO
 * @date 2018/10/7 15:54
 */
public class RaceCondition {

    private boolean state = false;

    public void test(){
        if (state){
            //做一些事
        }else{
            // 做另外一些事
        }
    }

    public void changeState(){
        if(state == false){
            state = true;
        }else{
            state = false;
        }
    }
}

代码很简单,test()方法会根据对象的state的状态执行一些操作,如果state是true就做一些操作,如果是false执行另外一些操作,在多线程条件下,线程A刚刚执行test()方法的,线程B可能已经改变了状态值,但其改变后的结果可能对A线程不可见,也就是说线程A使用的是过期值.这可能导致结果的错误.

5. 示例: 惰性初始化中的竞争条件

这个例子好,多线程环境下的单例模式.

/**
 * @author liuboren
 * @Title: Singleton
 * @ProjectName multithreading
 * @Description: TODO
 * @date 2018/10/7 16:29
 */
public class Singleton {
    private Singleton singleton;

    private Singleton() {
    }

    public Singleton getSingleton(){
        if(singleton ==null){
               singleton = new Singleton();
                      }
        return singleton;
    }
    
}

看这个例子,我们把构造方法声明为private的这样就只能通过getSingleton()来获得这个对象的实例了,先判断这个对象是否被实例化了,如果等于null,那就实例化并返回,看似很完美,在单线程环境下确实可以正常运行,但是在多线程环境下,有可能两个线程同时走到new对象这一行,这样就实例化了两个对象,这可能不是我们要的结果,我们来小小修改一下

/**
 * @author liuboren
 * @Title: Singleton
 * @ProjectName multithreading
 * @Description: TODO
 * @date 2018/10/7 16:29
 */
public class Singleton {
    private Singleton singleton;

    private Singleton() {
    }

    public Singleton getSingleton(){
        if(singleton ==null){
            synchronized (this) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
    
}

限于篇幅,这里直接改了一个完美版的,之所以不在方法声明 synchronized是为了减少同步快,实现更快的响应.

6 复合操作

为了避免竞争条件,必须阻止其他线程访问我们正在修改的变量,让我们可以确保:当其他线程想要查看或修改一个状态时,必须在我们的线程开始之前或者完成之后,而不能在操作过程中

将之前的自增操作改为原子的执行,可以让它变为线程安全的.使用Synchronized(同步)块,可以让操作变为原子的.

我们也可以使用原子变量类,是之前的代码变为线程安全的.

    private final AtomicLong count = new AtomicLong(0);

    @Override
    public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
        BigInteger i = extractFromRequest(servletRequest);
        BigInteger[] factors = factor(i);
        count.incrementAndGet();
        encodeIntoResponse(servletResponse, factors);
    }

7 锁

Java提供关键字Synchronized(同步)块,来保证线程安全,可以在多线程条件下保证可见性和原子性.

可见性: 一个线程修改完对象的状态后,对其他线程可见.

原子性: 可以把复合操作转换为不可再分的原子操作.一个线程执行完原子操作其它线程才能执行同样的原子操作.

让我们看看另一个关于线程安全的结论:当一个不变约束涉及多个变量时,变量间不是彼此独立的:某个变量的值会制约其他几个变量的值.因此,更新一个变量的时候,要在同一原子操作中更新其他几个.

觉得过于抽象?我们来看看实际的代码

/**
 * @author liuboren
 * @Title: StatelessServlet
 * @ProjectName multithreading
 * @Description: TODO
 * @date 2018/10/7 15:04
 */
public class StatelessServlet implements Servlet {
    private final AtomicReference<BigInteger> lastNumber
            = new AtomicReference<>();

    private final AtomicReference<BigInteger[]> lastFactors
            = new AtomicReference<>();


    @Override
    public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
        BigInteger i = extractFromRequest(servletRequest);
        if (i.equals(lastNumber.get())) {
            encodeIntoResponse(servletResponse, lastFactors.get());
        } else {
            BigInteger[] factors = factor(i);
            lastFactors.set(factors);
            encodeIntoResponse(servletResponse, lastFactors.get());
/        }
    }

简单说明一下,AtomicLong是Long和Integer的线程安全holder类,AtommicReference是对象引用的线程安全holder类. 可以保证他们可以原子的set和get.

我们看一下代码,根据lastNumber.get()的结果取返回lastFactors.get()的结果,这里存在竞争条件.因为很有可能线程A执行完lastNumber.set()且还没有执行lastFactors.set()的时候,另一个线程重新调用这个方法进行条件判断,lastNumber.get()取到了最新值,通过判断进行响应,但这时响应的lastFactors.get()却是过期值!!!!

FBI WARNING: 为了保护状态的一致性,要在单一的原子操作中更新相互关联的状态变量.

8 内部锁

每个对象都有一个内部锁,执行线程进入synchronized快之前获得锁;而无论通过正常途径退出,还是从块中抛出异常,线程在放弃对synchronized块的控制时自动释放锁.获得内部锁的唯一途径是:进入这个内部锁保护的同步块或方法.

内部锁是互斥锁,意味着至多只有一个线程可以拥有锁,当线程A尝试请求一个被线程B占有的锁时,线程A必须等待或者阻塞,直到B释放它,如果B永远不释放锁,A将永远等待下去

内部锁对提高线程的安全性来说很好,很perfect,but但是,在上锁的时间段其他线程被阻塞了,这会带来糟糕的响应性.

我们再来看之前的单例模式

/**
 * @author liuboren
 * @Title: Singleton
 * @ProjectName multithreading
 * @Description: TODO
 * @date 2018/10/7 16:29
 */
public class Singleton {
    private Singleton singleton;

    private Singleton() {
    }

 /*   public Singleton getSingleton(){
        if(singleton ==null){
            synchronized (this) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }*/

    public synchronized Singleton getSingleton() {
        if (singleton == null) {
            singleton = new Singleton();
        }
        return singleton;
    }
}

在方法上加synchronized可以保证线程安全,但是响应性不好,上面注解掉的是之前优化后的方法.

9 用锁来保护状态

下面列举了一些需要加锁的情况.

1. 操作共享状态的复合操作必须是原子的,以避免竞争条件.例如自增和惰性初始化.

2. 并不是所有数据都需要锁的保护---只有那些被多个线程访问的可变数据.

3. 对于每一个涉及多个变量的不变约束,需要同一个锁保护其所有变量

10 活跃度与性能
虽然在方法上声明 synchronized可以获得线程安全性,但是响应性变得很感人.

限制并发调用数量的,并非可用的处理器资源,而恰恰是应用程序自身的结构----我们把这种运行方式描述为弱并发的一种表现.

通过缩小synchronized块的范围来维护线程安全性,可以很容易提升代码的并发性,但是不应该把synchronized块设置的过小,而且一些很耗时的操作(例如I/O操作)不应该放在同步块中(容易引发死锁)

决定synchronized块的大小需要权衡各种设计要求,包括安全性、简单性和性能,其中安全性是绝对不能妥协的,而简单性和性能又是互相影响的(将整个方法声明为synchronized很简单,但是性能不太好,将同步块的代码缩小,可能很麻烦,但是性能变好了)

原则:
通常简单性与性能之间是相互牵制的,实现一个同步策略时,不要过早地为了性能而牺牲简单性(这是对安全性潜在的妥协).

最后,使用锁的时候,一些耗时非常长的操作,不要放在锁里面,因为线程长时间的占有锁,就会引起活跃度(死锁)与性能风险的问题.

嗯,终于写完了.以上是博主<<Java并发编程实战>>的学习笔记,如果对您有帮助的话,请点下推荐,谢谢.

posted @ 2018-10-07 20:26 lbr617 阅读(786) 评论(1) 编辑收藏举报

刷新页面返回顶部

天道酬勤

一分耕耘一分收获.