从构建分布式秒杀系统聊聊为什么不用synchronized

前言

技术没有高低之分,适合自己的就是最好的。只有努力扩展自己的知识边界,才能探索更多未知领域。

案例

在分析为什么不用 synchronized 这个问题之前,我们先用代码说话,LockDemo 测试案例:

/**
 * 案例测试
 * @author
 */
public class LockDemo {

    private static Lock lock = new ReentrantLock();

    private static int num1 = 0;
    private static int num2 = 0;
    public static void main(String[] args) {
        lockDemo();
        SyncDemo();
    }
    /**
     * 本机测试下20万自增基本能确定性能,但是不是特别明显,50万差距还是挺大的
     * 20万以下数据synchronized优于Lock
     * 20万以上数据Lock优于synchronized
     */
    public static void lockDemo(){
        long start = System.currentTimeMillis();
        for(int i=0;i<500000;i++){
            final int num = i;
            new Runnable() {
                @Override
                public void run() {
                    lock(num);
                }
            }.run();
        }
        long end = System.currentTimeMillis();
        System.out.println("累加:"+num1);
        System.out.println("ReentrantLock锁:"+ (end-start));
    }
    public static void SyncDemo(){
        long start = System.currentTimeMillis();
        for(int i=0;i<500000;i++){
            final int num = i;
            new Runnable() {
                @Override
                public void run() {
                    sync(num);
                }
            }.run();
        }
        long end = System.currentTimeMillis();
        System.out.println("累加:"+num2);
        System.out.println("synchronized锁:"+ (end-start));
    }
    public static void lock(int i){
        lock.lock();
        num1 ++;
        lock.unlock();
    }
    public static synchronized void sync(int i){
        num2 ++;
    }
}

50万++测试数据:

累加:500000
ReentrantLock锁:20
累加:500000
synchronized锁:28

用数据说话,很明显在高并发下,ReentrantLock 的性能是要优于 synchronized 的,虽然仅仅是几毫秒的差距,当然这里我并没有对比CPU的使用情况。

10万++测试数据:

累加:100000
ReentrantLock锁:13
累加:100000
synchronized锁:8

分析

这时候小伙伴可能会问了,有没有一个准确的临界值,来区分使用这两种锁?当然,在回答这个问题之前,先了解一下这两种锁到底有何异同。

锁的实现

Synchronized是依赖于JVM实现的,表现为原生语法层面的互斥锁。开发者是无法直接看到相关源码,但是我们可以通过利用javap工具查看生成的class文件信息来分析Synchronize的实现。同步代码块是使用monitorenter和monitorexit指令实现的,同步方法依靠的是方法修饰符上的ACC_SYNCHRONIZED实现。

ReenTrantLock是基于JDK实现的,一个表现为API层面的互斥锁,开发人员通过查阅源码就可以了解到。

可重入性

ReenTrantLock 的字面意思就是再进入的锁,synchronized关键字所使用的锁也是可重入的,两者关于这个的区别不大。

功能区别

Synchronized的使用比较方便,不需要开发者手动加锁和释放锁,而ReenTrantLock需要手工声明来加锁和释放锁(lock() 和 unlock() 方法配合 try/finally 语句块来实现)

ReenTrantLock 在锁的细粒度和灵活度上要优于Synchronized。此外,还增加了一些高级特性,主要有以下3项:等待可中断、可实现公平锁以及锁可以绑定多个条件。

发展历史

关于synchronized 与ReentrantLock

在JDK 1.6之后,虚拟机对于synchronized关键字进行整体优化后,在性能上synchronized与ReentrantLock已没有明显差距,因此在使用选择上,需要根据场景而定,大部分情况下我们依然建议是synchronized关键字,原因之一是使用方便语义清晰,二是性能上虚拟机已为我们自动优化。而ReentrantLock提供了多样化的同步特性,如超时获取锁、可以被中断获取锁(synchronized的同步是不能中断的)、等待唤醒机制的多个条件变量(Condition)等,因此当我们确实需要使用到这些功能是,可以选择ReentrantLock

原文地址:https://blog.51cto.com/14230003/2443061

时间: 2024-07-31 06:50:40

从构建分布式秒杀系统聊聊为什么不用synchronized的相关文章

从构建分布式秒杀系统聊聊Lock锁使用中的坑

前言 在单体架构的秒杀活动中,为了减轻DB层的压力,这里我们采用了Lock锁来实现秒杀用户排队抢购.然而很不幸的是尽管使用了锁,但是测试过程中仍然会超卖,执行了N多次发现依然有问题.输出一下代码吧,可能大家看的比较真切: @Service("seckillService") public class SeckillServiceImpl implements ISeckillService { /** * 思考:为什么不用synchronized * service 默认是单例的,并发

从构建分布式秒杀系统聊聊限流的多种实现

前言 俗话说的好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的.两周前秒杀案例初步成型,分享到了中国最大的同×××友网站-码云.同时也收到了不少小伙伴的建议和投诉.我从不认为分布式.集群.秒杀这些就应该是大厂的专利,在互联网的今天无论什么时候都要时刻武装自己,只有这样,也许你的春天就在明天. 在开发秒杀系统案例的过程中,前面主要分享了队列.缓存.锁和分布式锁以及静态化等等.缓存的目的是为了提升系统访问速度和增强系统的处理能力:分布式锁解决了集群下数据的安全一致性问题:静态化无疑

从构建分布式秒杀系统聊聊限流特技

前言 俗话说的好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的.两周前秒杀案例初步成型,分享到了中国最大的同性交友网站-码云.同时也收到了不少小伙伴的建议和投诉.我从不认为分布式.集群.秒杀这些就应该是大厂的专利,在互联网的今天无论什么时候都要时刻武装自己,只有这样,也许你的春天就在明天. 在开发秒杀系统案例的过程中,前面主要分享了队列.缓存.锁和分布式锁以及静态化等等.缓存的目的是为了提升系统访问速度和增强系统的处理能力:分布式锁解决了集群下数据的安全一致性问题:静态化无疑是

从构建分布式秒杀系统聊聊分布式锁

前言 最近懒成一坨屎,学不动系列一波接一波,大多还都是底层原理相关的.上周末抽时间重读了周志明大湿的 JVM 高效并发部分,每读一遍都有不同的感悟.路漫漫,借此,把前段时间搞着玩的秒杀案例中的分布式锁深入了解一下. 案例介绍 在尝试了解分布式锁之前,大家可以想象一下,什么场景下会使用分布式锁? 单机应用架构中,秒杀案例使用ReentrantLcok或者synchronized来达到秒杀商品互斥的目的.然而在分布式系统中,会存在多台机器并行去实现同一个功能.也就是说,在多进程中,如果还使用以上JD

从构建分布式秒杀系统聊聊验证码

前言 为了拦截大部分请求,秒杀案例前端引入了验证码.淘宝上很多人吐槽,等输入完秒杀活动结束了,对,结束了...... 当然了,验证码的真正作用是,有效拦截刷单操作,让羊毛党空手而归. 验证码 那么到底什么是验证码呢?验证码作为一种人机识别手段,其终极目的,就是区分正常人和机器的操作.我们常见的互联网注册.登录.发帖.领优惠券.投票等等应用场景,都有被机器刷造成各类损失的风险. 目前常见的验证码形式多为图片验证码,即数字.字母.文字.图片物体等形式的传统字符验证码.这类验证码看似简单易操作,但实际

从构建分布式秒杀系统聊聊WebSocket推送通知

前言 秒杀架构到后期,我们采用了消息队列的形式实现抢购逻辑,那么之前抛出过这样一个问题:消息队列异步处理完每个用户请求后,如何通知给相应用户秒杀成功? 场景映射 首先,我们举一个生活中比较常见的例子:我们去银行办理业务,一般会选择相关业务打印一个排号纸,然后就可以坐在小板凳上玩着手机,等待被小喇叭报号.当小喇叭喊到你所持有的号码,就可以拿着排号纸去柜台办理自己的业务. 这里,假设当我们取排号纸的时候,银行根据时间段内的排队情况,比较人性化的提示用户:排队人数较多,您是否继续等待?否的话我们可以换

SpringBoot开发案例从0到1构建分布式秒杀系统

前言 最近,被推送了不少秒杀架构的文章,忙里偷闲自己也总结了一下互联网平台秒杀架构设计,当然也借鉴了不少同学的思路.俗话说,脱离案例讲架构都是耍流氓,最终使用SpringBoot模拟实现了部分秒杀场景,同时跟大家分享交流一下. 秒杀场景 秒杀场景无非就是多个用户在同时抢购一件或者多件商品,专用词汇就是所谓的高并发.现实中经常被大家喜闻乐见的场景,一群大妈抢购打折鸡蛋的画面一定不会陌生,如此场面让服务员大姐很无奈,赶上不要钱了. 业务特点 瞬间高并发.电脑旁边的小哥哥.小姐姐们如超市哄抢的大妈一般

利用开源架构ELK构建分布式日志系统

本文介绍了如何使用成熟的经典架构ELK(即Elastic search,Logstash和Kibana)构建分布式日志监控系统,很多公司采用该架构构建分布式日志系统,包括新浪微博,freewheel,畅捷通等. 背景日志,对每个系统来说,都是很重要,又很容易被忽视的部分.日志里记录了程序执行的关键信息,ERROR和WARNING信息等等.我们可以根据日志做很多事情,做数据分析,系统监控,排查问题等等 .但是,任何一个中大型系统都不可能是单台Server,日志文件散落在几十台甚至成千上万台Serv

从无到有构建亿级微服务秒杀系统

从无到有构建亿级微服务秒杀系统(真实工业界案例) 题取马:zuoz 课成滴志::https://pan.baidu.com/s/1yiNyYTbqMG4PWC4XBoYmJg 录制本套教程的初衷,通过从业10年接触过很多的技术开发人员,尤其在面试一些技术人员的时候,发现他们的技术知识更新较慢,很多人渴望接触到高并发系统和一些高级技术架构,为了帮助更多人能够提升自己和接触到这类技术架构,并满足企业的人才需求,利用业余时间开启了我录制这套教程.通过业余录制的课程有很多学员给我反馈信息,给了我很大的鼓