java中的锁怎么实现,java分布式锁使用场景

　　00-1010 1、同步1.1、共享资源初始化2、CountDownLatch2.1、场景2.2、实现3、摘要

目录

synchronized是一个可重入的排他锁，与ReentrantLock功能相似。在任何使用synchronized的地方，都可以使用ReentrantLock。它们之间最大的相似之处是可重入的排他锁，它们之间的区别如下：

　　ReentrantLock的功能更多，比如提供条件，锁定可中断的API，满足锁队列的复杂场景等等；ReentrantLock可分为公平锁和不公平锁，synchronized lock为不公平锁；两者的使用姿势也不同。ReentrantLock需要声明的是，有加锁和释放锁的API，synchronized会自动加锁和释放代码块上的锁。同步的用起来更方便。Synchronized和ReentrantLock的功能差不多，我们就以synchronized为例。

　　00-1010在分布式系统中，我们喜欢在项目启动的时候把一些死的配置资源锁到JVM内存中，这样当请求取这些共享的配置资源的时候，就可以直接从内存中取，而不是每次都从数据库中取，这样就减少了时间成本。

　　通用共享资源包括：死业务流程配置和死业务规则配置。

　　共享资源初始化的步骤一般是：启动项目——触发初始化动作——单线程从数据库中取数据——组装成我们需要的数据结构——放入JVM的内存中。

　　项目启动时，为了防止共享资源被多次加载，我们往往会添加独占锁，这样在一个线程加载完共享资源后，另一个线程可以继续加载。这时候我们可以选择synchronized或者ReentrantLock进行独占锁。以synchronized为例，我们编写了如下的mock代码：

　　//共享资源privatestatic final mapstring，string shared _ map=maps . newconcurrentmap()；//是否有标志位private static boolean loaded=false表示初始化完成；/* * *初始化共享资源*/@ post构造public void init(){ if(loaded){ return；} synchronized (this){ //再次检查(loaded){ return；} log . info(“synchronized demo init begin”)；//从数据库中获取数据，组装成SHARED_MAP的数据格式。loaded=truelog . info( synchronized demo init end )；}}}不知道大家有没有从上面的代码中找到@PostConstruct注释。@PostConstruct注释的作用是在Spring容器初始化的时候执行注释标记的方法，也就是说上面提到的init方法的触发时间就是Spring容器启动的时候。

　　您可以下载演示代码，找到DemoApplication启动文件，并在DemoApplication文件上右键单击run来启动整个Spring Boot项目。您可以通过在init方法上创建一个断点来调试它。

　　我们在代码中使用synchronized来保证同一时间只有一个线程可以初始化共享资源，并且我们添加了一个共享资源的标志位(loaded)来判断加载是否完成。如果加载完成，其他加载线程将直接返回。

　　如果将synchronized改为ReentrantLock，实现是一样的，只是需要使用ReentrantLock显示的API来锁定和释放锁。使用ReentrantLock需要注意的一点是，我们需要在try方法块中锁定，在finally方法块中释放锁定，这样才能保证即使在try中锁定后出现异常，也能在finally中正确释放锁定。

　　有的同学可能会问，不能直接用ConcurrentHashMap吗？为什么需要上锁？诚然，ConcurrentHashMap是线程安全的，但它只能保证Map内部数据操作的线程安全，并不能保证查询数据库和组装数据的整个动作在多线程的情况下只执行一次。我们用synchronized锁定整个操作，以确保整个操作只执行一次。

1、synchronized

　　ass="maodian">

2.1、场景

1：小明在淘宝上买了一个商品，觉得不好，把这个商品退掉(商品还没有发货，只退钱)，我们叫做单商品退款，单商品退款在后台系统中运行时，整体耗时 30 毫秒。

　　2：双 11，小明在淘宝上买了 40 个商品，生成了同一个订单（实际可能会生成多个订单，为了方便描述，我们说成一个），第二天小明发现其中 30 个商品是自己冲动消费的，需要把 30 个商品一起退掉。

2.2、实现

此时后台只有单商品退款的功能，没有批量商品退款的功能（30 个商品一次退我们称为批量），为了快速实现这个功能，同学 A 按照这样的方案做的：for 循环调用 30 次单商品退款的接口，在 qa 环境测试的时候发现，如果要退款 30 个商品的话，需要耗时：30 * 30 = 900 毫秒，再加上其它的逻辑，退款 30 个商品差不多需要 1 秒了，这个耗时其实算很久了，当时同学 A 提出了这个问题，希望大家帮忙看看如何优化整个场景的耗时。

　　同学 B 当时就提出，你可以使用线程池进行执行呀，把任务都提交到线程池里面去，假如机器的 CPU 是 4 核的，最多同时能有 4 个单商品退款可以同时执行，同学 A 觉得很有道理，于是准备修改方案，为了便于理解，我们把两个方案都画出来，对比一下：

　　同学 A 于是就按照演变的方案去写代码了，过了一天，抛出了一个问题：向线程池提交了 30 个任务后，主线程如何等待 30 个任务都执行完成呢？因为主线程需要收集 30 个子任务的执行情况，并汇总返回给前端。

　　大家可以先不往下看，自己先思考一下，我们前几章说的那种锁可以帮助解决这个问题？

　　CountDownLatch 可以的，CountDownLatch 具有这种功能，让主线程去等待子任务全部执行完成之后才继续执行。

　　此时还有一个关键，我们需要知道子线程执行的结果，所以我们用 Runnable 作为线程任务就不行了，因为 Runnable 是没有返回值的，我们需要选择 Callable 作为任务。

　　我们写了一个 demo，首先我们来看一下单个商品退款的代码：

// 单商品退款，耗时 30 毫秒，退款成功返回 true，失败返回 false@Slf4jpublic class RefundDemo { /** * 根据商品 ID 进行退款 * @param itemId * @return */ public boolean refundByItem(Long itemId) { try { // 线程沉睡 30 毫秒，模拟单个商品退款过程 Thread.sleep(30); log.info("refund success,itemId is {}", itemId); return true; } catch (Exception e) { log.error("refundByItemError,itemId is {}", itemId); return false; } }}

接着我们看下 30 个商品的批量退款，代码如下：

@Slf4jpublic class BatchRefundDemo {// 定义线程池 public static final ExecutorService EXECUTOR_SERVICE = new ThreadPoolExecutor(10, 10, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(20)); @Test public void batchRefund() throws InterruptedException { // state 初始化为 30 CountDownLatch countDownLatch = new CountDownLatch(30); RefundDemo refundDemo = new RefundDemo(); // 准备 30 个商品 List<Long> items = Lists.newArrayListWithCapacity(30); for (int i = 0; i < 30; i++) { items.add(Long.valueOf(i+"")); } // 准备开始批量退款 List<Future> futures = Lists.newArrayListWithCapacity(30); for (Long item : items) { // 使用 Callable，因为我们需要等到返回值 Future<Boolean> future = EXECUTOR_SERVICE.submit(new Callable<Boolean>() { @Override public Boolean call() throws Exception { boolean result = refundDemo.refundByItem(item); // 每个子线程都会执行 countDown，使 state -1 ，但只有最后一个才能真的唤醒主线程 countDownLatch.countDown(); return result; } }); // 收集批量退款的结果 futures.add(future); } log.info("30 个商品已经在退款中"); // 使主线程阻塞，一直等待 30 个商品都退款完成，才能继续执行 countDownLatch.await(); log.info("30 个商品已经退款完成"); // 拿到所有结果进行分析 List<Boolean> result = futures.stream().map(fu-> { try { // get 的超时时间设置的是 1 毫秒，是为了说明此时所有的子线程都已经执行完成了 return (Boolean) fu.get(1,TimeUnit.MILLISECONDS); } catch (InterruptedException e) { e.printStackTrace(); } catch (ExecutionException e) { e.printStackTrace(); } catch (TimeoutException e) { e.printStackTrace(); } return false; }).collect(Collectors.toList()); // 打印结果统计 long success = result.stream().filter(r->r.equals(true)).count(); log.info("执行结果成功{},失败{}",success,result.size()-success); }}

上述代码只是大概的底层思路，真实的项目会在此思路之上加上请求分组，超时打断等等优化措施。

　　我们来看一下执行的结果:

　　从执行的截图中，我们可以明显的看到 CountDownLatch 已经发挥出了作用，主线程会一直等到 30 个商品的退款结果之后才会继续执行。

　　接着我们做了一个不严谨的实验（把以上代码执行很多次，求耗时平均值），通过以上代码，30 个商品退款完成之后，整体耗时大概在 200 毫秒左右。

　　而通过 for 循环单商品进行退款，大概耗时在 1 秒左右，前后性能相差 5 倍左右，for 循环退款的代码如下：

long begin1 = System.currentTimeMillis();for (Long item : items) { refundDemo.refundByItem(item);}log.info("for 循环单个退款耗时{}",System.currentTimeMillis()-begin1);

性能的巨大提升是线程池 + 锁两者结合的功劳。

3、总结

本章举了实际工作中的两个小案列，看到了 CountDownLatch 和 synchronized（ReentrantLock） 是如何结合实际需求进行落地的，特别是 CountDownLatch 的案列，使用线程池 + 锁结合的方式大大提高了生产效率，所以在工作中如果你也遇到相似的场景，可以毫不犹豫地用起来。

　　以上就是Java各种锁在工作中使用场景和细节经验总结的详细内容，更多关于Java锁在工作中使用场景细节的资料请关注盛行IT其它相关文章！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。