信号量

#模块：Lock #导入方法：from multiprocessing import Process,Lock #模块方法： l=Lock() l.acquire() #对所访问的资源加锁 l.release() #释放锁 #使用方法：一般在需要访问的资源的那部分代码加锁释放锁，但在初学阶段可以先包含整段程序 ###########模拟抢票程序 from multiprocessing import Process,Lock import time #在进行买票的时候，多个进程间有可能会出现第一个进程虽然先到达了，但是刚好时间片用完，这时候就会使得第一个到达的不一定会先买得到票 #不加锁的话，有可能在打开文件的时候另一个进程也打开了该文件，导致买到票的一个进程中的结果没有保存就被另一个进程所用了，以至于可能造成一张票多个人购买成功的情况 def check(i): with open("residue") as f: count=int(f.read()) #文件读取时为字符串类型，需要转为整数类型进行判断 if count>0: print("第{}个人查到了余票为{}".format(i,count)) else: print("已经没有票了") def purchase(i,l): #进行加锁操作 l.acquire() with open("residue") as f:

“我找到好办法了！” 没有想到，说话的人竟然是磁盘！ 进程调度器瑟瑟的说：“你有方法？还是算了吧，我怕用你的方法操作系统要乱套了。” 磁盘委屈的道：“不就是刚刚冤枉你了吗，这么小气干什么！再说了，这个方法不是我想出来的，是我从文件里找到的。” 操作系统挑了挑眉毛：“哦？你找到什么文件了，让大家也瞅瞅？” 磁盘嗡嗡的转起来，很快就把文件取出来了。 “当当当当~ 这可是大师 Dijkstra 的论文，他引入了一个全新的变量类型—— 信号量 （semaphore）。然后还为信号量设置了两种操作， P （proberen，检测） 和 V （verhogen，增量） 。” ”说清楚点啊，信号量是怎么个用法啊？“进程急切的问道。 “别急，让我接着看。。。Dijkstra 提出， P 操作是检测信号量是否为正值，如果不是，就阻塞调用进程。 V 操作能唤醒一个阻塞进程，让他恢复执行 。具体点的话就是这样： “ // S 为信号量 P(s): { S = S - 1 if (S < 0) { 调用该 P 操作的进程阻塞，并插入相应的阻塞队列； } } // S 为信号量 V(s): { S = S + 1 if (S <= 0) { 从等待信号量 S 的阻塞队列里唤醒一个进程； } } 内存仔细看了代码，说：”这个实现也要求是 原子操作 诶，Dijkstra 这个方法很有趣啊。“ 进程蒙圈了：

概述 在微服务架构中，将系统拆分为很多服务单元，各个单元的应用通过服务的注册与订阅的方式互相依赖。由于每个单元都在不同的进程中进行，依赖通过远程调用的方式执行，这样就可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后出现挤压，导致服务自身瘫痪。 针对上述的问题，Spring Cloud Hystrix实现了断路器、线程隔离等一些列服务保护功能。目标在于:通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更加强大的容错能力。Hytrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大的功能。 1.原理分析 工作流程: 1.创建HystrixCommand或HystrixObservableCommand对象 首先创建上面的两个对象之一来表示依赖服务的操作请求，同时传递所有需要的参数。采用”命令模式”来实现对服务调用操作的封装。 HystrixCommand:用于依赖的服务返回单个操作的时候 HystrixObservableCommand:用在依赖的服务返回多个操作结果的时候 2.命令执行 Hystrix在执行时会根据创建的Command对象以及具体的情况来选择一个执行。其中HystrixCommand实现俩个执行方式. execute():同步执行

信号量 信号量（ sem ）在操作系统中是一种实现系统中任务与任务、任务与中断间同步或者临界资源互斥保护的机制。在多任务系统中，各任务之间常需要同步或互斥，信号量就可以为用户提供这方面的支持。 抽象来说，信号量是一个非负整数，每当信号量被获取（ pend ）时，该整数会减一，当该整数的值为 0 时，表示信号量处于无效状态，将无法被再次获取，所有试图获取它的任务将进入阻塞态。通常一个信号量是有计数值的，它的计数值可以用于系统资源计数（统计）。 一般来说信号量的值有两种： 0：表示没有积累下来的 post 信号量操作，且可能有任务阻塞在此信号量上。 正值：表示有一个或多个 post 信号量操作。 一般来说信号量多用于同步而非互斥，因为操作系统中会提供另一种互斥机制（互斥锁），互斥量的互斥作用更完善：互斥锁有优先级继承机制，而信号量则没有这个机制，此外互斥量还拥有所有者属性，我们会在后续讲解。 信号量也如队列一样，拥有 阻塞机制 。任务需要等待某个中断发生后，再去执行对应的处理，那么任务可以处于阻塞态等待信号量，直到中断发生后释放信号量后，该任务才被唤醒去执行对应的处理。在释放（ post ）信号量的时候能立即将等待的任务转变为就绪态，如果任务的优先级在就绪任务中是最高的，任务就能立即被运行，这就是操作系统中的“ 实时响应，实时处理 ”。在操作系统中使用信号量可以提高处理的效率。

互斥锁 互斥锁又称互斥互斥锁，是一种特殊的信号量，它和信号量不同的是，它具有 互斥锁所有权、递归访问以及优先级继承 等特性，在操作系统中常用于对临界资源的 独占式 处理。在任意时刻互斥锁的状态只有两种， 开锁或闭锁 ，当互斥锁被任务持有时，该互斥锁处于闭锁状态，当该任务释放互斥锁时，该互斥锁处于开锁状态。 一个任务持有互斥锁就表示它拥有互斥锁的所有权，只有该任务才能释放互斥锁，同时其他任务将不能持有该互斥锁，这就是互斥锁的 所有权 特性。 当持有互斥锁的任务再次获取互斥锁时不会被挂起，而是能递归获取，这就是互斥锁的 递归访问 特性。这个特性与一般的信号量有很大的不同，在信号量中，由于已经不存在可用的信号量，任务递归获取信号量时会发生挂起任务最终形成 死锁 。 互斥锁还拥有 优先级继承 机制，它可以将 低 优先级任务的优先级 临时提升 到与获取互斥锁的 高 优先级任务的优先级 相同 ，尽可能 降低 优先级翻转的危害。 在实际应用中，如果想要实现同步功能，可以使用信号量，虽然互斥锁也可以用于任务与任务间的同步，但互斥锁更多的是用于临界资源的互斥访问。 使用互斥锁对临界资源保护时，任务必须先获取互斥锁以获得访问该资源的所有权，当任务使用资源后，必须释放互斥锁以便其他任务可以访问该资源（而使用信号量保护临界资源时则可能发生优先级翻转，且 危害 是不可控的）。 优先级翻转

同步的三个方法: 必须在同步块 或者同步方法中使用 notify() 停止访问当前线程,转去执行挂起的线程 notifyALL() wait() 挂起 释放对线程资源的访问 class CommonTalkVar{ private char product; /**同步信号量 * true: 持有产品状态 * false: 已经消费产品状态 * */ private boolean isProduced=false; /** * @description production method */ public synchronized void putCommonData(char product){ if(isProduced){ try { System.out.println(Thread.currentThread().getName()+"消费者还没有消费产品"); wait(); }catch (InterruptedException e){ e.printStackTrace(); } } this.product=product; this.isProduced=true; System.out.println(Thread.currentThread().getName()+"生产者生产:"+this.product); notify(); } /** *

互斥锁 互斥锁的特性： 1. 原子性：当有一个线程成功拿到了这个锁，其他线程都无法在相同的时间拿到这个锁 2. 唯一性：在一个线程拿到锁的这段时间，只有当这个线程把锁释放掉，其他的线程才有可能拿到 3. 非繁忙等待性：如果一个线程已经锁定了一个互斥量，第二个线程又视图去拿到这个锁的前线，则第二个锁将被挂起，等待第一个线程对互斥量解锁位置，同时第二个线程获取锁，继续往下执行 pthread_mutex_init pthread_mutex_lock pthread_mutex_trylock pthread_mutex_unlock pthread_mutex_destroy 信号量 信号量相当于一个加强版的互斥锁，提高了共同访问共享资源的线程数目（从串行，变成了并行） sem_init sem_wait sem_trywait sem_post sem_getvalue sem_destroy 条件变量 自动阻塞一个线程，直到某种特殊的情况发生为止，通常条件变量和互斥锁相互配合使用。 条件变量使得我们可以睡眠等待某种条件出现，条件变量是利用线程间共享的全局变量进行同步的一个机制。 条件变量主要包括两个动作： 1. 一个线程等待 “条件变量的成立“ 2. 另一个线程使得 “条件成立” 条件变量的作用： 1. 先把调用线程放到等待条件的队列上 2. 释放指定的锁以提供其他线程添加任务

锁汇总 👉 乐观锁 分为三个阶段：数据读取、写入校验、数据写入。 假设数据一般情况下不会造成冲突，只有在数据进行提交更新时，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回错误信息，让用户决定如何去做。fail-fast机制。 https://github.com/aalansehaiyang/technology-talk/blob/master/system-architecture/%E9%94%81%E6%9C%BA%E5%88%B6.md 👉 悲观锁 正如其名，它指对数据被外界（可能是本机的其他事务，也可能是来自其它服务器的事务处理）的修改持保守态度。在整个数据处理过程中，将数据处于锁定状态。悲观锁大多数情况下 依靠数据库的锁机制实现，以保证操作最大程度的独占性 。如果加锁的时间过长，其他用户长时间无法访问，影响程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是长事务而言，这样的开销往往无法承受。 👉 分布式锁 分布式集群中，对锁接口QPS性能要求很高，单台服务器满足不了要求，可以考虑将锁服务部署在独立的分布式系统中，比如借助分布式缓存来实现。 基于 redis分布式锁 基于 zookeeper实现的分布式锁 👉 可重入锁 可重入锁，也叫做递归锁，是指在同一个线程在调外层方法获取锁的时候，再进入内层方法会自动获取锁。ReentrantLock

创建信号量，并赋予初值 int sem_init(sem_t *sem, int pshared, unsigned int value); 销毁信号量 int sem_destroy(sem_t *sem); 阻塞，信号量数值-1 int sem_wait(sem_t *sem); 非阻塞申请 int sem_trywait(sem_t *sem); 计时申请一个信号量 int sem_timedwait(sem_t *sem, const struct timespec *abs_timeout); 发送信号量，数值 +1 int sem_post(sem_t *sem); 获取信号量值 int sem_getvalue(sem_t *sem, int *sval); 示例：和互斥锁案例相同 1 #include <stdio.h> 2 #include <unistd.h> 3 #include <stdlib.h> 4 #include <semaphore.h> 5 6 7 void* task1(void *arg); 8 void* task2(void *arg); 9 void* task3(void *arg); 10 11 static int i = 10 ; 12 static sem_t sem; //信号量指针 13 14 15 int main

Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景 本文介绍阿里开源限流熔断方案Sentinel功能、原理、架构、快速入门以及相关框架比较 基本介绍 1 名词解释 服务限流 ：当系统资源不够，不足以应对大量请求，对系统按照预设的规则进行流量限制或功能限制 服务熔断 ：当调用目标服务的请求和调用大量超时或失败，服务调用方为避免造成长时间的阻塞造成影响其他服务，后续对该服务接口的调用不再经过进行请求，直接执行本地的默认方法 服务降级 ：为了保证核心业务在大量请求下能正常运行，根据实际业务情况及流量，对部分服务降低优先级，有策略的不处理或用简单的方式处理 服务降级的实现可以基于人工开关降级（秒杀、电商大促等）和自动检测（超时、失败次数、故障），熔断可以理解为一种服务故障降级处理 2 为什么需要限流降级 系统承载的访问量是有限的，如果不做流量控制，会导致系统资源占满，服务超时，从而所有用户无法使用，通过服务限流控制请求的量，服务降级省掉非核心业务对系统资源的占用，最大化利用系统资源，尽可能服务更多用户 3 Sentinel简介 Sentinel: 分布式系统的流量防卫兵，是阿里中间件团队2018年7月开源的，面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来保护系统服务的稳定性 Sentinel 的开源生态：