CAS

　　在学习Java锁的时候，总觉的比较含糊，感觉一直没有系统的消化理解。所以决定重新梳理一下java相关的锁。 　 　 本质来说只有两种锁，乐观锁和悲观锁，其他所谓的可重入、自旋、偏向/轻量/重量锁等，都是锁具有的一些特点或机制。目的就是在数据安全的前提下，提高系统的性能。 乐观锁 　　 乐观锁，顾名思义，就是说在操作共享资源时，它总是抱着乐观的态度进行，它认为自己可以成功地完成操作。但实际上，当多个线程同时操作一个共享资源时，只有一个线程会成功，那么失败的线程呢？它们不会像悲观锁一样在操作系统中挂起，而仅仅是返回，并且系统允许失败的线程重试，也允许自动放弃退出操作。所以，乐观锁相比悲观锁来说，不会带来死锁、饥饿等活性故障问题，线程间的相互影响也远远比悲观锁要小。更为重要的是，乐观锁没有因竞争造成的系统开销，所以在性能上也是更胜一筹。 　　CAS 是实现乐观锁的核心算法，它包含了 3 个参数：V（需要更新的变量）、E（预期值）和 N（最新值）。只有当需要更新的变量等于预期值时，需要更新的变量才会被设置为最新值，如果更新值和预期值不同，则说明已经有其它线程更新了需要更新的变量，此时当前线程不做操作，返回 V 的真实值。 　　 如何实现原子操作 　　在 JDK 中的 concurrent 包中，atomic 路径下的类都是基于 CAS 实现的。AtomicInteger 就是基于

3 月，跳不动了？>>> 　　 　　本文为 何适原创并发编程系列 第 16 篇，文末有本系列文章汇总。 　　上一篇提到重入锁 ReentrantLock 支持两种锁，公平锁与非公平锁。那么这篇文章就来介绍一下公平锁与非公平锁。 　　为什么需要公平锁？ 　　ReentrantLock 如何是实现公平锁和非公平锁的？ 　　公平锁和非公平锁又都有什么优缺点呢？ 　　饥饿 　　我们知道 CPU 会根据不同的调度算法进行线程调度，将时间片分派给线程，那么就可能存在一个问题：某个线程可能一直得不到 CPU 分配的时间片，也就不能执行。 　　 一个线程因为得不到 CPU 运行时间 ，就会处于饥饿状态。如果该线程一直得不到 CPU 运行时间的机会，最终会被“饥饿致死”。 　　1.1 导致线程饥饿的原因 　　 高优先级线程吞噬所有的低优先级线程的 CPU 时间。 　　每个线程都有独自的线程优先级，优先级越高的线程获得的 CPU 时间越多，如果并发状态下的线程包括一个低优先级的线程和多个高优先级的线程，那么这个低优先级的线程就有可能因为得不到 CPU 时间而饥饿。 　　 线程被永久堵塞在一个等待进入同步块的状态。 　　当同步锁被占用，线程处在 BLOCKED 状态等锁。当锁被释放，处在 BLOCKED 状态的线程都会去抢锁，抢到锁的线程可以执行，未抢到锁的线程继续在 BLOCKED 状态阻塞

3 月，跳不动了？>>> ReentrantLock是CAS使用的典型，本文通过分析lock()方法的源码，了解ReentrantLock是如何在不加锁的前提下，通过CAS实现线程安全操作的， 来源： oschina 链接： https://my.oschina.net/leitingweb/blog/3207257

3 月，跳不动了？>>> ThreadLocalRandom继承了Random接口，并且实现了Serializable接口，就已经知道了它的真身！ 因为Random的实现由于原子变量的更新是 CAS 操作，同时只有一个线程会成功，所以会造成大量线程进行自旋重试，这是会降低并发性能的，所以 ThreadLocalRandom 应运而生。 在并发程序中使用ThreadLocalRandom而不是共享Random对象通常会更少的开销和争用。当多个任务（例如，每个ForkJoinTask）在线程池中并行使用随机数时，使用ThreadLocalRandom是特别合适的。 ThreadLocalRandom在java.util.concurrent包下，是一个与当前线程隔离的随机数生成器。 类的用法通常应为以下形式：ThreadLocalRandom.current().nextX（...）（其中X为Int，Long等）。当所有用法都是这种形式时，永远不可能在多个线程中意外地共享ThreadLocalRandom。 该类还提供了其他常用的有界随机生成方法。 通过current方法ThreadLocalRandom实例,会先调用localInit方法初始化一些参数： 实现上的细节比较多，不是很明白，先来看看怎么用的吧 输出： nextInt​():返回伪随机int值 这里的int mix32

3 月，跳不动了？>>> 今天我们讲解一下CAS的多种认证方式，在上一篇文章中我们讲解了CAS基础服务的搭建，完成了CAS认证服务中心的简单部署，如果忘记了话，可以先去复习一下—— CAS单点登录(二)——搭建基础服务 。 CAS认证方式有多种，我们可以根据自己的需求来实现。在前一篇文章中搭建服务中我们其实就把CAS的JDBC认证方式讲解了，在读取用户名我们可以指定为从数据库的表中读取数据。 一、 JDBC认证 我们还是接着上次的代码进行讲解，你可以先下载先前的代码—— Chapter1 。上次在CAS基本服务搭建的代码中，我们只是简单的使用了一下，今天我们将完善更多的配置。 在前面我们设计了一个user表，表的字段为： 常用单向加密算法：MD5、SHA、HMAC。 一般我们常用的加密算法就这几种。在JDBC认证中我们也可以选择配置加密算法，加密算法一般为上面的三种，MD5、SHA、HMAC，加密类型为 NONE|DEFAULT|STANDARD|BCRYPT|SCRYPT|PBKDF2 这几种，我们在配置文件中选择加密类型，指定加密算法。 前面配置不变指定JDBC配置，后面的配置为密码加密策略，配置如下： ## # JDBC配置 # #查询账号密码SQL，必须包含密码字段 cas.authn.jdbc.query[0].sql=select * from user where

3 月，跳不动了？>>> 前一篇文章中，我们对CAS及SSO（单点登录）有了大致的了解，今天我们开始讲解如何搭建一个简单的CAS服务认证中心，如果你对CAS中单点登录的概念忘记了，可以先去复习一下先前的文章—— CAS单点登录(一)——初识SSO ，再开始接下来的内容。 一、搭建CAS基础服务 1、准备 首先CAS官方文档地址： https://apereo.github.io/cas/5.3.x/index.html ，在后面我们可能随时会用到。 然后我们从 Geting Started 开始，在文档里面告诉我们部署CAS，推荐我们使用WAR Overlay method的方法，利用覆盖机制来组合CAS原始工件和本地自定义方法来达到自定义CAS的要求。 It is recommended to build and deploy CAS locally using the WAR Overlay method. This approach does not require the adopter to explicitly download any version of CAS, but rather utilizes the overlay mechanism to combine CAS original artifacts and local customizations

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为JA-SIG 的一个项目。CAS 具有以下特点： 【1】开源的企业级单点登录解决方案。 【2】CAS Server 为需要独立部署的 Web 应用。 【3】CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。 从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程： SSO单点登录访问流程主要有以下步骤： 1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。 2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。 3. 用户认证：用户身份认证。 4. 发放票据：SSO服务器会产生一个随机的Service Ticket。 5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。 6. 传输用户信息：SSO服务器验证票据通过后

1、CAS（compare and swap） CAS 概念： CAS是一种系统原语，能够原子地完成比较和交换两个动作（所谓原语属于操作系统用语范畴。原语由若干条指令组成的，用于完成一定功能的一个过程。primitive or atomic action 是由若干个机器指令构成的完成某种特定功能的一段程序，具有不可分割性·即原语的执行必须是连续的，在执行过程中不允许被中断）。CAS是Compare And Set的缩写。CAS有3个操作数，内存值V，旧的预期值E，要修改的新值N。当且仅当预期值E和内存值V相同时，将内存值V修改为B，否则什么都不做。 CAS 执行流程图： 2、自旋锁 （spinlock） 前言： 在介绍自旋锁之前，需要提到关键字 Volatile，它可以保证 JMM 模型所规定的可见性+有序性，但是它却不能保证原子性，即如果用它是不能保证对修饰变量操作的原子性的。因此不能用它来作为锁，但是它配合上 CAS 就可以构造出一种“无锁策略”的乐观自旋锁，保证了操作的原子性，而且在适合其应用的场景下效率是比较高的，因为它的优点就是可以避免线程的上下文切换所带来的系统开销。 概念： 是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。 自旋锁缺点： 1）如果某个线程持有锁的时间过长

某厂面试归来，发现自己落伍了！>>> 前言：其实好早就想把CAS的这一套知识整合一下，在工作上也应用到了这块，只是最近才在工作上接触到CAS，所以刚好把这些知识总结一下。这块可能是一个比较大的模块知识点，所以会有多篇文章进行逐一展开，笔者会尽量抽空更新，当然如果文章中存在错误，期望大家指出。 一、初识CAS 首先我们来说一下CAS，CAS全称为Central Authentication Service即中央认证服务，是一个企业多语言单点登录的解决方案，并努力去成为一个身份验证和授权需求的综合平台。 CAS是由Yale大学发起的一个企业级的、开源的项目，旨在为Web应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。 CAS协议至少涉及三方：客户端Web浏览器，请求身份验证的Web应用程序和CAS服务器。 它也可能涉及后端服务，如数据库服务器，它没有自己的HTTP接口，但与Web应用程序进行通信。 主要特征： 多种的协议的支持，包括CAS (v1、v2、v3)、SAML(v1、v2)、OAuth、OpenID、OpenID Connect和WS-Federation Passive Requestor 多种认证机制，可以通过JAAS，LDAP，RDBMS，X.509，Radius，SPNEGO，JWT，Remote，Trusted，BASIC，Apache Shiro

某厂面试归来，发现自己落伍了！>>> 附上最近更新的面经： 某大佬的20+公司面试题总结和自己的补充 一面 自我介绍下自己，不超过3分钟（实际上我的自我介绍不到一分钟） 你感觉比本科阶段自己进步了多少，有哪些进步 研究生期间最大的进步是什么 你觉得你适合从事哪个方向的开发 synchronized与lock的区别，使用场景。看过synchronized的源码没 JVM自动内存管理，Minor GC与Full GC的触发机制 了解过JVM调优没，基本思路是什么 如果CPU使用率较高，GC频繁且GC时间长，可能就需要JVM调优了。 基本思路就是让每一次GC都回收尽可能多的对象， 对于CMS来说，要合理设置年轻代和年老代的大小。该如何确定它们的大小呢？这是一个迭代的过程，可以先采用JVM的默认值，然后通过压测分析GC日志。 如果看年轻代的内存使用率处在高位，导致频繁的Minor GC，而频繁GC的效率又不高，说明对象没那么快能被回收，这时年轻代可以适当调大一点。 如果看年老代的内存使用率处在高位，导致频繁的Full GC，这样分两种情况：如果每次Full GC后年老代的内存占用率没有下来，可以怀疑是内存泄漏；如果Full GC后年老代的内存占用率下来了，说明不是内存泄漏，要考虑调大年老代。 对于G1收集器来说，可以适当调大Java堆，因为G1收集器采用了局部区域收集策略