码迷,mamicode.com
首页 > 编程语言 > 详细

Java常见编程错误:锁

时间:2020-04-25 23:56:44      阅读:123      评论:0      收藏:0      [点我收藏+]

标签:共享资源   adl   unlock   总结   void   val   readwrite   art   object   

分析解决线程安全问题的锁在使用中的问题。

场景:

在?个类?有两个int类型的字段a和b,有?个add?法循环1万次对a和b进 ?++操作,有另?个compare?法,同样循环1万次判断a是否?于b,条件成?就打印a和b的值,并判断 a>b是否成?。

代码如下:

volatile int a = 1;
    volatile int b = 1;

    int loop=10000000;

    public void add() {
        System.out.println("add start");
        for (int i = 0; i < loop; i++) {
            a++;
            b++;
        }
        System.out.println("add done");
    }

    public void compare() {
        System.out.println("compare start");
        for (int i = 0; i < loop; i++) {
            //a始终等于b吗?
            if (a < b) {
                System.out.println(a + "," + b + "," + (a > b));
                //最后的a>b应该始终是false吗?
            }
        }

        System.out.println("compare done");
    }

    public static void main(String[] args) {
        LockTest test = new LockTest();
        new Thread(() -> test.add()).start();
        new Thread(() -> test.compare()).start();
    }

按道理,a和b同样进?累加操作,应该始终相等,compare中的第?次判断应该始终不会成?,不会输出任何?志。但,执?代码后发现不但输出了?志,?且更诡异的是,compare?法在判断a<b成?的情况下还输出了a>b也成?:

9899491,9899492,false
9899949,9899950,true
9900959,9900959,false
9901787,9901786,true

 

解决方案1:

操作两个字段a和b,有线程安全问题,为add?法加上锁,确保a和b的++是原?性的,就不会错乱 了。

public synchronized void add()

加锁后问题并没有解决。

来仔细想?下,为什么锁可以解决线程安全问题呢。因为只有?个线程可以拿到锁,所以加锁后的代码 中的资源操作是线程安全的。

但是,这个案例中的add?法始终只有?个线程在操作,显然只为add?法加锁是没?的

之所以出现这种错乱,是因为两个线程是交错执?add和compare?法中的业务逻辑,?且这些业务逻辑不
是原?性的:a++和b++操作中可以穿插在compare?法的?较代码中;更需要注意的是,a<b这种?较操
作在字节码层?是加载a、加载b和?较三步,代码虽然是??但也不是原?性的。

解决方案2:

正确的做法应该是,为add和compare都加上?法锁,确保add?法执?时,compare?法读取a和 b:

public synchronized void add()
public synchronized void compare()

所以,使?锁解决问题之前?定要理清楚,我们要保护的是什么逻辑,多线程执?的情况?是怎样的。

 

加锁前要清楚锁和被保护的对象是不是?个层?的

除了没有分析清线程、业务逻辑和锁三者之间的关系随意添加?效的?法锁外,还有?种?较常?的错误是,没有理清楚锁和要保护的对象是否是?个层?的。

静态字段属于类,类级别的锁才能保护;??静态字段属于类实例,实例级别的锁就可以保护。

场景:

在类Data中定义了?个静态的int字段counter和?个?静态的wrong?法,实 现counter字段的累加操作。

代码如下:

static int count = 1000000;
    @Getter
    private static int counter = 0;

    public static int reset() {
        counter = 0;
        return counter;
    }

    public synchronized void wrong() {
        counter++;
    }

    public static void main(String[] args) {
        Data.reset();
        //多线程循环?定次数调?Data类不同实例的wrong?法
        IntStream.rangeClosed(1, count)
                .parallel()
                .forEach(i -> new Data().wrong());

        System.out.println(Data.getCounter());
    }

因为默认运?100万次,所以执?后应该输出100万,但实际输出的是673767:

问题分析:

在?静态的wrong?法上加锁,只能确保多个线程?法执?同?个实例的wrong?法,却不能保证不会执?不同实例的wrong?法。

?静态的counter在多个实例中共享,所以必然会出现线程安全问题。

解决方案:

同样在类中定义?个Object类型的静态字段,在操作counter之前对这个字段加锁。

static Object locker = new Object();

public void right() {
        synchronized (locker) {
            counter++;
        }
    }

 

加锁要考虑锁的粒度和场景问题

在?法上加synchronized关键字实现加锁确实简单,也因此曾看到?些业务代码中?乎所有?法都加了synchronized,但这种滥?synchronized的做法:

  • ?是,没必要。通常情况下60%的业务代码是三层架构,数据经过?状态的Controller、Service、 Repository流转到数据库,没必要使?synchronized来保护什么数据。
  • ?是,可能会极?地降低性能。使?Spring框架时,默认情况下Controller、Service、Repository是单例 的,加上synchronized会导致整个程序?乎就只能?持单线程,造成极?的性能问题。

即使我们确实有?些共享资源需要保护,也要尽可能降低锁的粒度,仅对必要的代码块甚?是需要保护的资源本?加锁。

场景:

在业务代码中,有?个ArrayList因为会被多个线程操作?需要保护,?有?段?较耗时的操作(代码中的slow?法)不涉及线程安全问题,应该如何加锁呢?

错误的做法是,给整段业务逻辑加锁,把slow?法和操作ArrayList的代码同时纳?synchronized代码块; 更合适的做法是,把加锁的粒度降到最低,只在操作ArrayList的时候给这个ArrayList加锁。

private List<Integer> data = new ArrayList<>();

    private void slow() {
        try {
            TimeUnit.MICROSECONDS.sleep(10);
        } catch (InterruptedException e) {

        }
    }


    public int wrong() {
        long begin = System.currentTimeMillis();
        IntStream.rangeClosed(1, 1000).parallel()
                .forEach(i -> {
                    //加锁粒度太粗了
                    synchronized (this) {
                        slow();
                        data.add(i);
                    }
                });
        System.out.println("took: " + (System.currentTimeMillis() - begin));
        return data.size();
    }

    public int right() {
        long begin = System.currentTimeMillis();
        IntStream.rangeClosed(1, 1000).parallel().forEach(i -> {
            slow();
            //只对List加锁
            synchronized (data) {
                data.add(i);
            }
        });
        System.out.println("took: " + (System.currentTimeMillis() - begin));
        return data.size();
    }

    public static void main(String[] args) {
        LockTest1 test = new LockTest1();
        new Thread(() -> test.wrong()).start();
        new Thread(() -> test.right()).start();
    }

 

如果精细化考虑了锁应?范围后,性能还?法满?需求的话,就要考虑另?个维度的粒度问题了,

即: 区分读写场景以及资源的访问冲突,考虑使?悲观?式的锁还是乐观?式的锁。

?般业务代码中,很少需要进?步考虑这两种更细粒度的锁,?概的结论:

  • 对于读写?例差异明显的场景,考虑使?ReentrantReadWriteLock细化区分读写锁,来提?性能;
  • JDK版本?于1.8、共享资源的冲突概率也没那么?的话,考虑使?StampedLock的乐观读的特 性,进?步提?性能;
  • JDK?ReentrantLock和ReentrantReadWriteLock都提供了公平锁的版本,在没有明确需求的情况下不要 轻易开启公平锁特性,在任务很轻的情况下开启公平锁可能会让性能下降上百倍。

多把锁要??死锁问题

锁的粒度够?就好,这就意味着我们的程序逻辑中有时会存在?些细粒度的锁。但?个业务逻 辑如果涉及多把锁,容易产?死锁问题。

案例:

下单操作需要锁定订单中多个商品的库存,拿到所有商品的锁之后进?下单扣 减库存操作,全部操作完成之后释放所有的锁。代码上线后发现,下单失败概率很?,失败后需要??重新 下单,极?影响了??体验,还影响到了销量。

经排查发现是死锁引起的问题,背后原因是扣减库存的顺序不同,导致并发的情况下多个线程可能相互持有 部分商品的锁,?等待其他线程释放另?部分商品的锁,于是出现了死锁问题。

代码示例:

定义?个商品类型,包含商品名、库存剩余和商品的库存锁三个属性,每?种商品默认库存1000 个;初始化10个这样的商品对象来模拟商品清单:

@Data
@RequiredArgsConstructor
public class Item {
    final String name; //商品名
    int remaining = 1000; //库存剩余
    //ToString不包含这个字段
    @ToString.Exclude
    ReentrantLock lock = new ReentrantLock();
}

写?个?法模拟在购物?进?商品选购,每次从商品清单(items字段)中随机选购三个商品(为了逻辑简单,不考虑每次选购多个同类商品的逻辑,购物?中不体现商品数量)

private List<Item> createCart() {
        return IntStream.rangeClosed(1, 3)
                .mapToObj(i -> "item" + ThreadLocalRandom.current().nextInt(items.size()))
                .map(name -> items.get(name)).collect(Collectors.toList());
    }

下单代码如下:先声明?个List来保存所有获得的锁,然后遍历购物?中的商品依次尝试获得商品的锁,最 ?等待10秒,获得全部锁之后再扣减库存;如果有?法获得锁的情况则解锁之前获得的所有锁,返回false 下单失败。

private boolean createOrder(List<Item> order) {
        //存放所有获得的锁
        List<ReentrantLock> locks = new ArrayList<>();
        for (Item item : order) {
            try {
                //获得锁10秒超时
                if (item.lock.tryLock(10, TimeUnit.SECONDS)) {
                    locks.add(item.lock);
                } else {
                    locks.forEach(ReentrantLock::unlock);
                    return false;
                }
            } catch (InterruptedException e) {
            }
        }
        //锁全部拿到之后执?扣减库存业务逻辑
        try {
            order.forEach(item -> item.remaining--);
        } finally {
            locks.forEach(ReentrantLock::unlock);
        }
        return true;
    }

 

写?段代码测试这个下单操作。模拟在多线程情况下进?100次创建购物?和下单操作,最后通过?志 输出成功的下单次数、总剩余的商品个数、100次下单耗时,以及下单完成后的商品库存明细:

public long wrong() {
        long begin = System.currentTimeMillis();
        //并发进?100次下单操作,统计成功次数
        long success = IntStream.rangeClosed(1, 100).parallel()
                .mapToObj(i -> {
                    List<Item> cart = createCart();
                    return createOrder(cart);
                })
                .filter(result -> result)
                .count();
        log.info("success:{} totalRemaining:{} took:{}ms items:{}",
                success,
                items.entrySet().stream().map(item -> item.getValue().remaining).reduce(0, Integer::sum),
                System.currentTimeMillis() - begin, items);
        return success;
    }

使?JDK?带的VisualVM?具来跟踪?下,重新执??法后不久就可以看到,线程Tab中提?了死锁问题

分析:

购物?添加商品的逻辑,随机添加了三种商品,假设?个购物?中的商品是item1和 item2,另?个购物?中的商品是item2和item1,

?个线程先获取到了item1的锁,同时另?个线程获取到 了item2的锁,然后两个线程接下来要分别获取item2和item1的锁,这个时候锁已经被对?获取了,只能相互等待?直到10秒超时。

解决方案:

为购物?中的商品排?下序,让所有的线程?定是先获取item1的锁然后获 取item2的锁,就不会有问题了。所以,我只需要修改??代码,对createCart获得的购物?按照商品名进?排序即可:

 long success = IntStream.rangeClosed(1, 100).parallel()
                .mapToObj(i -> {
                    List<Item> cart = createCart().stream()
                            .sorted(Comparator.comparing(Item::getName))
                            .collect(Collectors.toList());
                    return createOrder(cart);
                })
                .filter(result -> result)
                .count();

 

总结:

  • 使?synchronized加锁虽然简单,但我们?先要弄清楚共享资源是类还是实例级别的、会被哪些线 程操作,synchronized关联的锁对象或?法?是什么范围的。
  • 加锁尽可能要考虑粒度和场景,锁保护的代码意味着?法进?多线程操作。对于Web类型的天然多线 程项?,对?法进??范围加锁会显著降级并发能?,要考虑尽可能地只为必要的代码块加锁,降低锁的粒 度;?对于要求超?性能的业务,还要细化考虑锁的读写场景,以及悲观优先还是乐观优先,尽可能针对明 确场景精细化加锁?案,可以在适当的场景下考虑使?ReentrantReadWriteLock、StampedLock等?级的 锁?具类。
  • 业务逻辑中有多把锁时要考虑死锁问题,通常的规避?案是,避免?限等待和循环等待。

如果业务逻辑中锁的实现?较复杂的话,要仔细看看加锁和释放是否配对,是否有遗漏释放或重复释 放的可能性;并且要考虑锁?动超时释放了,?业务逻辑却还在进?的情况下,如果别的线线程或进程拿到 了相同的锁,可能会导致重复执?。

如果业务代码涉及复杂的锁操作,应该Mock相关外部接?或数 据库操作后对应?代码进?压测,通过压测排除锁误?带来的性能问题和死锁问题。

Java常见编程错误:锁

标签:共享资源   adl   unlock   总结   void   val   readwrite   art   object   

原文地址:https://www.cnblogs.com/liekkas01/p/12775880.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!