Java 中的 CAS 指两种完全无关技术：一是并发编程中的 Compare-And-Swap 原子操作，基于 CPU 指令实现无锁同步；二是单点登录领域的 Central Authentication Service 认证框架，依赖 HTTP 重定向与票据验证。
先分清两类 CAS，避免张冠李戴
• 并发 CAS：属于 Java 并发包底层核心，是 AtomicInteger、ConcurrentHashMap 等类的实现基础，解决多线程读写共享变量的安全问题。
• 单点登录 CAS：是一个开源 SSO 框架（现由 Apereo 维护），用于统一用户身份认证，让多个 Web 应用共用一套登录入口和登出逻辑。
两者唯一共同点是缩写都是 CAS，其余从设计目标到代码结构都完全不同。教程梳理必须从这个区分开始，否则后续所有内容都会错位。
并发 CAS 的核心逻辑要抓住三点
它不是 Java 语言特性，而是借助 CPU 指令（如 x86 的 cmpxchg）实现的硬件级原子操作：
立即学习“Java免费学习笔记（深入）”；
- 三个参数缺一不可：内存地址中的当前值 V、线程本地保存的预期值 A、待写入的新值 B
- 一次完成“读—比—写”：仅当 V == A 时才把 B 写入，否则失败返回 false，不阻塞线程
- Java 中通过
Unsafe.compareAndSwapInt()等 native 方法暴露，java.util.concurrent.atomic包里的类都基于它封装
单点登录 CAS 的关键流程在于票据流转
它不依赖 Java 并发模型，而是一套基于 HTTP 重定向与票据验证的协议体系：
- 用户首次访问应用 → 被重定向到 CAS Server 登录页 → 提交凭证 → 认证成功后颁发 TGT（Ticket-Granting Ticket）并存入服务端 Session
- 应用拿到 ST（Service Ticket）→ 后台用 ST 向 CAS Server 验证 → 获取用户身份信息 → 建立本地会话
- 登出时由 CAS Server 主动通知所有已注册客户端，销毁各自 Session，实现全局退出
学习路径建议按角色切入
• 如果你在写高并发业务或中间件：重点掌握 AtomicStampedReference 如何解决 ABA 问题、LongAdder 为何比 AtomicLong 更适合高冲突计数、以及 CAS 自旋对 CPU 的实际影响。
• 如果你在做系统集成或运维：关注 CAS Server 的部署方式（Tomcat + HTTPS）、客户端过滤器配置（CasAuthenticationFilter）、数据库认证适配、以及登出回调的可靠性保障。
• 切忌把 compareAndSet() 的返回值当成登录成功标志，也别用 synchronized 去“优化” CAS Server 的登录接口——那是两个世界的事。
