同步机制应遵循哪些基本准则为什么，互斥锁和自旋锁的区别面试

同步机制应遵守什么基本准则?为什么？

在多道程序环境下，当程序并发执行时，因为资源共享和进程合作，使同处于一个系统中的进程当中可能存在着以下两种形式的制约关系（1）间接相互制约关系，同处于一个系统中的进程，一般都共享着某种资源。

（2）直接相互制约关系，这样的制约主要源自于进程间的合作。

故此，使用系统中的临界资源时，诸进程应采用互斥方法，达到对资源的共享。

为达到进程互斥的进入自己的临界区，可用软件方式，但更多的是在系统中设置针对的同步机制来协调各进程间的运行。全部的同步机制都应遵守以下四条准则：

（1）空闲让进：因为，当无进程处于临界区时，表达临界资源处于空闲状态，应允许一个请求进入临界区的进程马上进入自己的临界区，以有效地利用临界资源。

（2）忙则等着：因为，当已有进程进入临界区时，表达临界资源已经在被访问，因而其它试图进入临界区的进程一定要等着，以保证对临界资源的互斥访问。

（3）有限等着：因为，对要求访问的临界资源的进程，应保证在在一定的有效时间内可以进到自己的临界区，避免陷入“死等”状态。

（4）让权等着：因为，当进程不可以进入自己的临界区时，应马上释放处理机，避免进程陷入“忙等”状态

互斥锁和自旋锁的区别？

在于它们采取的加锁方法不一样。

互斥锁在获取锁时会将现目前线程阻塞，等着其他线程释放锁，防止不一样线程同时操作共享资源，以此不要竞态条件。

而自旋锁则通过忙等的方法，不停地尝试获取锁，在锁被释放前持续忙等。

因为这个原因，自旋锁适用于锁定时间较短、竞争不激烈的情况，而互斥锁适用于锁定时间较长、竞争激烈的情况。

同时，自旋锁的加锁开销较小，但是，会占用CPU资源，而互斥锁的加锁开销很大，但是，不会占用CPU资源。需要大家特别注意的是，在多核处理器系统中，自旋锁的效果比在单核处理器系统中更为显著，因为在多核处理器系统中，线程被阻塞后，CPU可能会被分配给其他线程运行，致使线程阻塞时间变长，因为这个原因自旋锁更为适用。

互斥锁和自旋锁都是线程同步的机制，但它们在达到和使用上有一部分不一样：

1. 达到方法不一样：互斥锁一定要在内核态和用户态当中进行上文和下文切换，因为这个原因开销相对较大，而自旋锁是在用户态下执行，不用上文和下文切换，因为这个原因效率比互斥锁高。

2. 锁的获取方法不一样：当互斥锁被占耗费时长，线程会被挂起，直到锁被释放，线程被唤醒。而当自旋锁被占耗费时长，线程会进入一个忙等着的状态，一直等到锁被释放才会结束忙等着。

3. 互斥锁可用于不一样进程当中的同步，而自旋锁只可以在同一进程中使用。

4. 自旋锁适用于轻量级的锁，针对持有这个时间比较短的锁，使用自旋锁更为合适；而互斥锁适用于重量级的锁，针对持有这个时间较长的锁，使用互斥锁更为合适。

整体来说，互斥锁和自旋锁各有优缺点，需按照详细的场景选择。

mysql的同步复制和异步复制有哪些区别？

在谈这个特性以前，我们先来看看mysql的复制架构衍生史。 MySQL的复制分为三种： 第一种，即普通的replication。 搭建简单，使用很广泛，从mysql诞生之初，就出现了这样的架构，性能很好，可谓很成熟。 但是，这样的架构数据是异步的，故此，有丢失数据库的风险。 第二种，即mysql cluster。 搭建也简单，本身也比较稳定是mysql里面对数据保护靠谱的架构，也是唯一一个数据完全同步的架构，绝对的零丢失。不过性能就差远些了。第三种，即semi-sync replication，半同步，性能，功能都介于以上两者当中。从mysql5.5启动诞生，目标是为了折中上面说的两种架构的性能还有优缺点。“我们今天谈论第三种架构

我们清楚，普通的replication，也即mysql的异步复制，依靠mysql二进制日志也即binary log进行数据复制。例如两台机器，一台主机也即master，另外一台是从机，也即slave。

1. 正常的复制为：事务一（t1）写入binlog buffer；dumper 线程公告slave有新的事务t1；binlog buffer 进行checkpoint；slave的io线程接收到t1并写入到自己的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都可以看到这条新的事务，就算master挂了，slave可以提高为新的master。 2. 异常的复制为：事务一（t1）写入binlog buffer；dumper 线程公告slave有新的事务t1；binlog buffer 进行checkpoint；slave因为互联网不稳定，一直没有收到t1；master 挂掉，slave提高为新的master，t1丢失。

3. 很大的问题是：主机和从机事务更新的不一样步，就算是没有互联网或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，致使很大的推后。

为了补上来以上几种场景的不够，mysql从5.5启动推出了半同步。

也就是在master的dumper线程公告slave后，增多了一个ack，即是不是成功收到t1的标志码。其实就是常说的dumper线程除了发送t1到slave，还担负了接收slave的ack工作。假设产生异常，没有收到ack，既然如此那，将自动降级为普通的复制，直到异常修复。

我们可以看到半同步带来的新问题： 1. 假设异常出现，会降级为普通的复制。 既然如此那，从机产生数据不完全一样的几率会减少，并非完全消失。 2. 主机dumper线程担负的工作变多了，这样明显会降低整个数据库的性能。 3. 在MySQL 5.5和5.6使用after_commit的模式下, 即假设slave 没有收到事务，其实就是常说的还没有写入到relay log 以前，互联网产生异常或者不稳定，这个时候刚好master挂了，系统切换到从机，两边的数据就可以产生不完全一样。 在这里情况下，slave会少一个事务的数据。

随着MySQL 5.7版本的公布，半同步复制技术升级为全新的Loss-less Semi-Synchronous Replication架构，其成熟度、数据完全一样性与执行效率得到显著的提高。

MySQL 5.7对数据复制效率进行了改进1 主从完全一样性加强支持在事务commit前等着ACK

新版本的semi sync 增多了rpl_semi_sync_master_wait_point参数 来控制半同步模式下 主库在返回给会话事务成功以前提交事务的方法。

该参数有两个值：

AFTER_COMMIT（5.6默认值）

master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等着slave 反馈收到relay log，唯有收到ACK后master才将commit OK结果反馈给客户端。

AFTER_SYNC（5.7默认值，但5.6中无此模式）

master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等着slave 反馈接收到relay log的ack后面，再提交事务还返回commit OK结果给客户端。 就算主库crash，全部在主库上已经提交的事务都可以保证已经同步到slave的relay log中。

因为这个原因5.7引入了after_sync模式，带来的主要收益是处理after_commit致使的master crash主从间数据不完全一样问题，因为这个原因在引入after_sync模式后，全部提交的数据已经都被复制，故障切换时数据完全一样性将得到提高。

2 性能提高支持发送binlog和接受ack的异步化

旧版本的semi sync 受限于dump thread ，因素是dump thread 担负了两份不一样且又十分频繁的任务：传送binlog 给slave ，还要有等着slave反馈信息，而且，这两个任务是串行的，dump thread 一定要等着 slave 返回后面才会传送下一个 events 事务。dump thread 已然成为整个半同步提升性能的无法提升的尴尬境地。在高并发业务场景下，这样的机制会影响数据库整体的TPS .

图：Without ACK receiving thread

为了处理上面说的问题，在5.7版本的semi sync 框架中，独立出一个 ack collector thread ，针对用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。

图：With ACK receiving thread3 性能提高控制主库接收slave 写事务成功反馈数量

MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count参数，可以用来控制主库接受多少个slave写事务成功反馈，给高可用架构切换提供了灵活性。

如图所示，当count值为2时，master需等着两个slave的ack

4 性能提高

Binlog 互斥锁改进

旧版本半同步复制在主提交binlog的写会话和dump thread读binlog的操作都会对binlog添加互斥锁，致使binlog文件的读写是串行化的，存在并发度的问题。

MySQL 5.7对binlog lock进行了以下两方面优化

1.移除了dump thread对binlog的互斥锁

2.加入了安全边际保证binlog的读安全

5 性能提高组提交

5.7引入了新的变量slave-parallel-type，其可以配置的值有：

DATABASE （5.7以前默认值），根据库的并行复制方法；LOGICAL_CLOCK （5.7新增值），根据组提交的并行复制方法；

MySQL 5.6版本也支持这里说的的并行复制，但是，其并行只是根据DATABASE的，其实就是常说的根据库的。假设用户的MySQL数据库实例中存在多个DATABASE ，针对从机复制的速度的确可以有相对较大的帮，假设用户实例仅仅只有一个库，既然如此那，就没办法达到并行回放，甚至性能会比原来的单线程更差。

MySQL5.7中增多了一种新的并行模式：为同时进入COMMIT阶段的事务分配一样的序列号，这些拥有一样序列号的事务在备库是可以并发执行的。

MySQL 5.7真正达到的并行复制，这里面为主要的因素就是slave服务器的回放与主机是完全一样的即master服务器上是咋并行执行的slave上就怎样进行并行回放。不可以再有库的并行复制限制，针对二进制日志格式也无特殊的要求（根据库的并行复制也不限制）。

因为这个原因下面的序列中可以并发的序列为（这当中前面一个数字为last_committed ，后面一个数字为sequence_number ）：

trx1 1…..2trx2 1………….3trx3 1…………………….4trx42……………………….5trx5 3…………………………..6trx6 3………………………………7trx76………………………………..8

备库并行规则：当分发一个事务时，其last_committed 序列号比现目前已经在执行的事务的小sequence_number要小时，则允许执行。

因为这个原因，

a)trx1执行，last_commit2的可并发，trx2, trx3可继续分发执行

b)trx1执行成功后，last_commit 3的可以执行， trx4可分发

c)trx2执行成功后，last_commit 4的可以执行， trx5, trx6可分发

d)trx3、trx4、trx5成功后，last_commit 7的可以执行，trx7可分发

综合上面所说得出所述

我们觉得MySQL 5.7版对Loss-Less半同步复制技术的优化，让其成熟度和执行效率都得到了质的提升。我们建议在使用MySQL 5.7作为生产环境的部署时，可以使用半同步技术作为高可用与读写分离方案的数据复制方案。

同步就是保证两边是完全一样完成的 异步是前一方成功后，另一方再完成且另一方假设不可以完成，影响不了前一方

synchronized的实质？

1、同步器的实质就是加锁

加锁目标：序列化访问临界资源，即同一时刻只可以有一个线程访问临界资源(同步互斥访问)

不过当多个线程执行一个方式时，该方式内部的局部变量并非临界资源，因为这些局部变量是在每个线程的私有栈中，因为这个原因不具有共享性，不可能会造成线程安全问题。

2、锁类型

隐式锁：Synchronized加锁机制是Jvm内置锁，不用手动加锁与解锁Jvm会自动加锁跟解锁。

显式锁：Lock；比如：ReentrantLock，达到juc里的Lock接口，达到是根据AQS达到，需手动加锁跟解锁ReentrantLock lock(), unlock();

长安cs35p进程通讯能做什么？

回答请看下方具体内容：长安CS35P进程通讯可以达到不一样进程当中的数据交换和通信。这针对一部分需协同完成任务的应用程序很有用，比如多线程应用、分布式系统等。通过进程通讯，不一样的进程可以共享数据和资源，达到协同工作和信息共享。在实质上应用中，长安CS35P进程通讯可以用于达到以下功能：

1. 分布式计算：不一样的进程可在不一样的计算机上运行，通过进程通讯达到分布式计算，提升计算效率。

2. 系统服务：通过进程通讯，不一样的进程可以共享系统服务，如打印服务、互联网服务等。

3. 数据库连接：通过进程通讯，不一样的进程可以共享数据库连接，达到数据共享和协同处理。

4. 多进程编程：通过进程通讯，不一样的进程可以协同完成一个任务，达到多进程编程。

总而言之，长安CS35P进程通讯可以为不一样的应用程序提供更强大的功能和更高效的协同工作方法，提升应用程序的性能和可靠性。

有关这个问题，长安CS35P进程通讯可以达到多个应用程序当中的数据交换和共享，比如：

1. 达到进程当中的数据传输，可以达到不一样进程当中的协作和信息共享。

2. 支持多线程并发操作，提升系统的效率和响应速度。

3. 达到远程过程调用（RPC）和分布式计算，可以将数据和计算任务分配到远程服务器上进行一定程度的处理。

4. 支持消息队列和进程间共享内存，可以达到进程当中的异步通信和高效的数据传输。

5. 通过进程通讯可以达到进程当中的互斥和同步，不要因为共享资源而出现的竞争和冲突。

C语言多线程线程同步可以干什么？

一：互斥与同步☆ 互斥：一个公共资源同一时刻只可以被一个进程或线程使用，多个进程或线程不可以同时使用公共资源。☆ 同步：两个或两个以上的进程或线程在运行途中协同步调，按预定的先后次序运行。☆ 处理方式：互斥锁，条件变量，读写锁，自旋锁，信号量（互斥与同步）☆ 二：互斥锁（同步）☆ 互斥锁是一种简单的加锁的方式来控制对共享资源的访问，互斥锁唯有两种状态,即上锁( lock )和解锁( unlock )。☆ 特点：唯一性，原子性，非繁忙等着☆ 三：条件变量（同步）☆ 条件变量是用来等着而不是用来上锁的。条件变量用来自动阻塞一个线程，直 到某情况特殊出现为止。合适多个线程等着某个条件的出现，不使用条件变量，既然如此那，每个线程就持续性尝试互斥锁并检测条件是不是出现，浪费系统资源。☆ 四：读写锁（同步）☆ 三种状态：读模式下加锁状态、写模式加锁状态、不加锁状态☆ 【读写锁的特点】：☆ 假设有其它线程读数据，则允许其它线程执行读操作，但不允许写操作；☆ 假设有其它线程写数据，则其它线程都不允许读、写操作。☆ 【读写锁的规则】：☆ 1：假设某线程申请了读锁，其它线程可以再申请读锁，但不可以申请写锁；☆ 2：假设某线程申请了写锁，其它线程不可以申请读锁，也不可以申请写锁。☆ 读写锁合适于对数据结构的读次数比写次数多得多的情况。☆ 五：自旋锁（同步）#includesemaphore.h☆ 自旋锁与互斥量功能一样，唯一一点不一样的就是互斥量阻塞后休眠让出cpu，而自旋锁阻塞后不会让出cpu，会一直忙等着，直到得到锁。自旋锁在用户态使用的很少，在内核使用的非常多！自旋锁的使用场景：锁的持有这个时间比较短，或者说小于2次上文和下文切换时间。☆ 六：信号量（同步与互斥）☆ 信号量实质上是一个非负的整数计数器，它被用来控制对公共资源的访问。☆ 编程时可按照操作信号量值的结果判断是不是对公共资源具有访问的权限，当信号量值大于 0 时，则可以访问，不然将阻塞。PV 原语是对信号量的操作，一次 P 操作使信号量减１，一次 V 操作使信号量加１。☆ ☆ ☆ ☆ ☆ ☆ ☆

p操作和v操作是否有先后顺序？

可以这样理解：

临界区门前有棵树

用来挂红灯

进程想进CPU的门

先得上树取下盏灯（调用一次P）

取下一个去敲门（S＝S－1）

假设树上没有灯取（S＜＝0）

树说暂时欠你一盏灯（S为负时）

进程没辙只好在门外边排队等（WAIT（S））

得灯的进程继续运行运行完了要出门（调用一次V）

马上还回一盏灯（S＝S＋1）

若有进程在催债（S＜＝0）

放个进程进去完成（Release（S））

没什么技巧，其实就是常说的进程一先v后p，进程二先p后v或者进程一先p后v，进程二先v后p或者同时先后pv，vp四种情况你比较一下，不一样的试题用不一样的顺序

（1）信号量的值减1，即S=S-1;（2）假设S≥0，则该进程继续执行;假设S＜0，则把该进程的状态置为阻塞态，把对应的PCB连入该信号量队列的末尾，并放弃处理机，进行等着(直至其它进程在S上执行V操作，把它释放出来为止)。V操作顺序执行下述两个动作:（1）S值加1，即S=S+1;（2）假设S＞0，则该进程继续运行;假设S≤0，则释放信号量队列上的第一个PCB(即信号量指量指针项所指向的PCB)所对应的进程(把阻塞态改成就绪态)，执行V操作的进程继续运行。1.PV操作的含义：PV操作由P操作原语和V操作原语组成（原语是不可中断的过程），对信号量进行操作，详细定义请看下方具体内容：P（S）：（1）将信号量S的值减1，即S=S-1；（2）假设S³0，则该进程继续执行；不然该进程置为等着状态，排入等着队列。V（S）：（1）将信号量S的值加1，即S=S+1；（2）假设S0，则该进程继续执行；不然释放队列中第一个等着信号量的进程。2.PV操作的意义：我们用信号量及PV操作来达到进程的同步和互斥。PV操作属于进程的低级通信。什么是信号量？信号量（semaphore）的数据结构为一个值和一个指针，指针指向等着该信号量的下一个进程。信号量的值与对应资源的使用情况相关。当它的值大于0时，表示现目前可用资源的数量；当它的值小于0时，其绝对值表示等着使用该资源的进程个数。注意，信号量的值仅能由PV操作来改变。3,  大多数情况下来说，信号量S³0时，S表示可用资源的数量。执行一次P操作说明了请求分配一个单位资源，因为这个原因S的值减1；当S

壳程和管程的区别？

区别：

1、性质不一样：管程在功能上和信号量及PV操作类似，属于一种进程同步互斥工具，但是，具有与信号量及PV操作不一样的属性。管壳式换热器是以封闭在壳体中约束的壁面作为传热面的间壁式换热器。

2、特点不一样：管壳式换热器结构简单、造价低、流通截面较宽、易于清洗水垢。管程封装了同步操作，对进程隐蔽了同步细节，简化了同步功能的调用界面。用户编写并发程序如同编写顺序(串行)程序。

3、组成不一样：管壳式换热器由壳体、传热约束、管板、折流板（挡板）和管箱等部件组成。管程局部数据和条件变量组成管程内的数据结构。

管程指介质流经换热器内的入口通道及与其相贯通的部分。壳程系指介质流经换热管外的入口通道及与其相贯通的部分。这个涉及到管壳式换热器流体选择问题，主要依据有两流体的操作压力和温度、能用到的压力降、结构和腐蚀性还有设备方面的考虑。

除了上面说的条件外，另外还要有考虑到传热系数和充分利用压力降，从压力降考虑，雷诺数低走壳程更合理。大多数情况下塔顶冷却器多数物料走壳程 冷却水走管程再沸器物料则走管程，蒸汽、凝液走壳程。

以上为相当大一部分是这样，也有特例子： 大多数情况下主物料走壳程，辅助加热、冷却介质走管程。现场判断的好方式是：管程介质从换热器一端进出，壳程介质靠中间一点进出，管程进出口一端要预留一定的抽换热器芯子的空间。

简单地说管程就是管内,壳程就是管外.就固定管板换热器来说,管壳程物料选择依据总体有:不洁净和易结垢的流体宜走管程,因管内清洗方便;腐蚀性流体宜走管程,避免约束和壳体同时受腐蚀,且清洗,检修方便;

压强高的流体宜走管程,避免壳体同时受压;有毒流体宜走管程,使泄漏机会减少;被冷却的流体宜走壳程,方便散热,提高冷却效果;饱和蒸汽宜走壳程,方便排出冷凝液和不凝气,且蒸汽洁净不污染；

流量小或粘度大的流体宜走壳程,因折流档板的作用能够让在低雷诺数下就可以达到湍流,但也可以在管内采取多管程;若两流体温差很大,宜使α大的流体走壳程,使管壁和壳壁温差减小.

管程和壳程区别：

大多数情况下来说，水、水蒸气或强腐蚀性流体；有毒性的流体；容易结垢的流体还有高压操作的流体走管程；而塔顶冷凝蒸汽；烃类冷凝和再沸；重要压力降控制的流体，粘度大的流体走壳程。

压力容器的壳程、管程分别是什么意思？？

壳程是指流体沿换热器的壳体、约束和档板 当中的空隙自左至右(或自右至左)所流经的距离。

管程在管式换热器中系指介质流经换热管内的入口通道及相贯通部分。

管程特点：管程封装了同步操作，对进程隐蔽了同步细节，简化了同步功能的调用界面。用户编写并发程序如同编写顺序(串行)程序。

引入管程机制的目标：

1、把分散在各进程中的临界区集中起来进行管理；

2、防止进程有意或无意的违法同步操作；

3、方便用高级语言来表达程序，也方便程序正确性验证。

压力容器制造工序大多数情况下可以分为：原材料验收工序、划线工序、切割工序、除锈工序、机加工（含刨边等）工序、滚制工序、组对工序、焊接工序（产品焊接试板）、无损检测工序、开孔划线工序、总检工序、热处理工序、压力试验工序、防腐工序。

不一样的焊接方式有不一样的焊接工艺。焊接工艺主要按照被焊工件的材质、牌号、化学成分，焊件结构类型，焊接性能要求来确定。

确定焊接方式，如手弧焊、埋弧焊、钨极氩弧焊、熔化极气体保护焊等等，焊接方式的种类很多，只可以按照详细情况选择。

确定焊接方式后，再制定焊接工艺参数，焊接工艺参数的种类各不一样，如手弧焊主要涵盖：焊条型号（或牌号）、直径、电流、电压、焊接电源种类、极性接法、焊接层数、道数、检验方式等等。

山西专升本备考资料及辅导课程

山西专升本培训班-名师辅导课程