CAS

面试官：说一下公平锁和非公平锁的区别？ 前言 上次我们提到了乐观锁和悲观锁，那我们知道锁的类型还有很多种，我们今天简单聊一下，公平锁和非公平锁两口子，以及他们在我们代码中的实践。 正文 开始聊之前，我先大概说一下他们两者的定义，帮大家回顾或者认识一下。 公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。 优点：所有的线程都能得到资源，不会饿死在队列中。 缺点：吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大。 非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。 优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。 缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。 我举个例子给他家通俗易懂的讲一下的，想了好几天终于在前天跟三歪去肯德基买早餐排队的时候发现了怎么举例了。 现在是早餐时间，敖丙想去kfc搞个早餐，发现有很多人了，一过去没多想，就乖乖到队尾排队，这样大家都觉得很公平，先到先得，所以这是公平锁咯。 那非公平锁就是，敖丙过去买早餐，发现大家都在排队，但是敖丙这个人有点渣的，就是喜欢插队，那他就直接怼到第一位那去，后面的鸡蛋

HSRP(Hot Standby Routing Protocol)热备份路由协议。 HSRP协议是思科的私有协议。VRRP是公有热备协议。 HSRP的作用： 网关冗余技术，让一台PC可以有两个网关，平时主的网关工作，当主的出现故障从网关则接替工作。主从网关由一个虚IP来决定谁是主谁是从。 HSRP组成员： 一台活跃路由器，一台备份路由器，一台虚拟路由器，其他路由器组成。 HSRP端口号位1985，属于UDP协议，数据包使用组播地址：224.0.0.2 TTL值为1。 HSRP的六种状态： 初始状态，学习状态，监听状态，发言状态，备份状态，活跃状态。 HSRP选举： 通过优先级选举谁是主谁是从，优先级数值越大则优先，默认值为100。 HSRP强占+端口跟踪： 相同条件下无法发生强占。当配置了端口跟踪，主优先级为100时，如果主路由器跟踪的端口出现问题，HSRP自动将优先级降10，这样从的优先级就会高于主的，自动强占。 HSRP默认的Hello时间为3S间隔，保持时间为10S。 思科热备技术相关命令： 命令 描述 (config-if)# standby 1 ip 192.168.1.1 配置虚IP (config-if)# standby 1 priority 105 配置优先级 (config-if)# standby 1 preempt 配置强占 (config-if)#

OSPF协议全称opend shortest path first开放式最短路径优先协议，它根据SPF算法自动选择最优的路经动态选择路由。 OSPF协议的优势：适用于大规模网络，路由变化收敛速度快，无环路由，支持子网划分LVSM，支持区域划分，支持组播发送报文，支持触发性更新路由条目。 OSPF协议是链路状态路由协议，它的管理距离为110。它的协议号为89。 SPF计算路径成本的公式：10的8次方除以BW（带宽）。单位：Bit/S。 AS叫自治系统：我们将共同管理下的一组路由运行的网络称之为自治系统。 OSPF的工作过程:建立邻接关系，链路状态数据库，最短路径树，形成路由表。 OSPF有三个表：邻居表，链路状态数据库，路由表。 OSPF形成邻接状态的过程：Down失效状态，Init初始化状态，2-Way邻居状态，Exstart开始状态，Exchange交换状态，Loading等待状态，Full邻接状态。 释义：从Down到2-Way这个阶段是路由与路由确认是邻居了，然后从Exstart到Full这个阶段完成邻接。邻接的意思就是邻居之间建立连接。 OSPF包类型： v Hell包：发生送Hell报文建立邻接关系。 v 数据库描述包DBD：发送描述列表，就是我这里有那几个网段。 v 链路状态请求包LSR：发送请求包，请求路由列表。 v 链路状态更新包LSU：发送更新包，更新路由列表。

一、概述 　　谈到并发，不得不谈ReentrantLock；而谈到ReentrantLock，不得不谈AbstractQueuedSynchronized（AQS）！ 　　类如其名，抽象的队列式的同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch...。 　　以下是本文的目录大纲： 概述 框架 源码详解 简单应用 　　若有不正之处，请谅解和批评指正，不胜感激。 　　请尊重作者劳动成果，转载请标明原文链接： http://www.cnblogs.com/waterystone/p/4920797.html 二、框架 　　它维护了一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。这里volatile是核心关键词，具体volatile的语义，在此不述。state的访问方式有三种: getState() setState() compareAndSetState() 　　AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。 　

互斥锁在 AQS的互斥锁与共享锁 中已经做了详细介绍，一个锁一次只能由一个线程持有，其它线程则无法获得，除非已持有锁的线程释放了该锁。这里为什么提互斥锁呢？其实互斥锁和自旋锁都是实现同步的方案，最终实现的效果都是相同的，但它们对未获得锁的线程的处理方式却是不同的。对于互斥锁，当某个线程占有锁后，另外一个线程将进入阻塞状态。与互斥锁类似，自旋锁保证了公共数据在任意时刻最多只能由一条线程获取使用，不同的是在获取锁失败后自旋锁会采取自旋的处理方式。 自旋锁 自旋锁是一种非阻塞锁，它的核心机制就在自旋两个字，即用自旋操作来替代阻塞操作。某一线程尝试获取某个锁时，如果该锁已经被另一个线程占用的话，则此线程将不断循环检查该锁是否被释放，而不是让此线程挂起或睡眠。一旦另外一个线程释放该锁后，此线程便能获得该锁。自旋是一种忙等待状态，过程中会一直消耗CPU的时间片。 为什么自旋 互斥锁有一个很大的缺点，即获取锁失败后线程会进入睡眠或阻塞状态，这个过程会涉及到用户态到内核态的调度，上下文切换的开销比较大。假如某个锁的锁定时间很短，此时如果锁获取失败则让它睡眠或阻塞的话则有点得不偿失，因为这种开销可能比自旋的开销更大。总结起来就是互斥锁更适合持有锁时间长的情况，而自旋锁更适合持有锁时间短的情况。 自旋锁特点 自旋锁的核心机制就是死等，所有想要获得锁的线程都在不停尝试去获取锁，当然这也会引来竞争问题。

点击上方 蓝色字体 ，选择“标星公众号” 优质文章，第一时间送达 作者 | 秋风飒飒吹 来源 | urlify.cn/IzqIB3 66套java从入门到精通实战课程分享 有时候，springboot官方提供的场景启动器(starter)并不能很好的满足我们的需求。 一些配置类仍然需要我们自行编写（例如mybatis plus的分页插件配置），在多模块项目中，这种模式代码可能多个模块都需要编写一次，这时候，我们可以考虑自行编写场景启动器，然后在common模块引入即可。 1、命名规约 spring官方： spring-boot-starter-xxx 自定义： xxx-spring--boot-starter 2、自定义starter步骤 2.1创建一个普通的空工程 2.2创建一个普通maven项目 这里我将工程命名为gulimall-spring-boot-starter 2.3创建自动配置模块 选择springboot工程构建工具： 模块命名为gulimall-spring-boot-autoconfigure。 这里可以啥都不选，后面可以自行修改 2.4修改pom文件 starter引入autoconfigure模块 autoconfigure模块，先删除build，然后删除spring-boot-test，再删除test包，因为用不到，我这里引入mybatis

synchronized实现原理 当一个线程试图访问同步代码块时，他首先必须得到锁，退出或抛出异常时必须释放锁。那么锁到底存在哪里呢？锁里面会存储什么信息呢？ 从JVM规范中可以看到Synchronized在JVM里的实现原理，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用monitorenter和monitorexit指令实现的，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明。但是，方法的同步同样可以使用这两个指令来实现。 monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。 i++ 是线程安全的吗？ 不是 每个线程都有自己的工作内存，每个线程需要对共享变量操作时必须先把共享变量从主内存 load 到自己的工作内存，等完成对共享变量的操作时再 save 到主内存。 问题就出在这了，如果一个线程运算完后还没刷到主内存

English | 中文 概述 MaxKey(马克思的钥匙) 单点登录认证系统(Single Sign On System)，寓意是最大钥匙,是 业界领先的企业级开源IAM身份管理和身份认证产品 ,支持OAuth 2.0/OpenID Connect、SAML 2.0、JWT、CAS、SCIM等标准协议，提供 简单、标准、安全和开放 的用户身份管理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC权限管理和资源管理等。 官方网站 官网 | 官网二线 QQ交流群： 434469201 邮箱email: maxkeysupport@163.com 代码托管 GitHub | 码云(Gitee) 什么是 单点登录(Single Sign On） ，简称为 SSO ？ 用户只需要登录认证中心一次就可以访问所有相互信任的应用系统，无需再次登录。 主要功能： 所有应用系统共享一个身份认证系统 所有应用系统能够识别和提取ticket信息 产品特性 标准认证协议： 序号 协议 支持 1.1 OAuth 2.0/OpenID Connect 高 1.2 SAML 2.0 高 1.3 JWT 高 1.4 CAS 高 1.5 FormBased 中 1.6 TokenBased(Post/Cookie) 中 1.7 ExtendApi 低 1.8 EXT 低 登录支持 序号 登录方式 2.1

这时需要配OWA服务的URL地址为单域名证书相应的地址如mail.xxx.com Get-ClientAccessServer xxx-cas01 | select AutoDiscoverServiceexternalUri Set-ClientAccessServer xxx-cas01 -autodiscoverServiceInternalUrl https://mail.xxx.com/autodiscover/autodiscover.xml 其他如mapi、OWA、ECP等虚拟目录也需要在图形化界面上设置 mail.xxx.com 来源： oschina 链接： https://my.oschina.net/u/4260217/blog/4872474

如何解决高并发秒杀的超卖问题 由秒杀引发的一个问题 秒杀最大的一个问题就是解决超卖的问题。 其中一种解决超卖如下方式： 1 update goods set num = num - 1 WHERE id = 1001 and num > 0 我们假设现在商品只剩下一件了，此时数据库中 num = 1； 但有100个线程同时读取到了这个 num = 1 ，所以100个线程都开始减库存了。 但你会最终会发觉， 其实只有一个线程减库存成功，其他99个线程全部失败。 为何？ 这就是MySQL中的排他锁起了作用。 排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存， 如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁 ，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。 就是类似于我在执行update操作的时候，这一行是一个事务 (默认加了排他锁 )。 这一行不能被任何其他线程修改和读写 第二种解决超卖的方式如下 1 select version from goods WHERE id = 1001 2 update goods set num = num - 1 , version = version + 1 WHERE id = 1001 AND num > 0 AND version = @version (上面查到的version);