上一篇文章 可见性有序性，Happens-before来搞定，解决了并发三大问题中的两个，今天我们就聊聊如何解决原子性问题 原子性问题的源头就是 线程切换，但在多核 CPU 的大背景下，不允许线程切换是不可能的，正所谓「魔高一尺，道高一丈」，新规矩来了: 互斥: 同一时刻只有一个线程执行 实际上，上面这句话的意思是: 对共享变量的修改是互斥的，也就是说线程 A 修改共享变量时其他线程不能修改，这就不存在操作被打断的问题了，那么如何实现互斥呢？ 锁 对并发有所了解的小伙伴马上就能想到 锁 这个概念，并且你的第一反应很可能就是使用 synchronized，这里列出来你常见的 syn

写在前面 上一篇文章并发 Bug 之源有三，请睁大眼睛看清它们 谈到了可见性/原子性/有序性三个问题，这些问题通常违背我们的直觉和思考模式，也就导致了很多并发 Bug * 为了解决 CPU，内存，IO 的短板，增加了缓存，但这导致了可见性问题 * 编译器/处理器擅自优化 ( Java代码在编译后会变成 Java 字节码, 字节码被类加载器加载到 JVM 里, JVM 执行字节码, 最终需要转化为汇编指令在 CPU 上执行) ，导致有序性问题 初衷是好的，但引发了新问题，最有效的办法就禁止缓存和编译优化，问题虽然能解决，但「又回到最初的起点，呆呆地站在镜子前」是很尴尬的，我们程序的性能就

写在前面 * 生活中你一定听说过——能者多劳 * 作为 Java 程序员，你一定听过——这个功能请求慢，能加一层缓存或优化一下 SQL 吗？ * 看过中国古代神话故事的也一定听过——天上一天，地上一年 一切设计来源于生活，上一章 学并发编程，透彻理解这三个核心是关键 中有讲过，作为”资本家”，你要尽可能的榨取 CPU，内存与 IO 的剩余价值，但三者完成任务的速度相差很大，CPU > 内存 > IO分，CPU 是天，那内存就是地，内存是天，那 IO 就是地，那怎样平衡三者，提升整体速度呢？ 1. CPU 增加缓存，还不止一层缓存，平衡内存的慢 2. CPU 能者多劳，通过分时

拦截器介绍 Mybatis Interceptor 在 Mybatis 中被当作 Plugin(插件)，不知道为什么，但确实是在 org.apache.ibatis.plugin 包下面 既然是拦截器，可以拦截哪些内容呢？试想一下…… 当程序写到持久层时，Mybatis 会 执行 指定 SQL 语句，并处理 请求参数 和 返回值。没错，Mybatis 拦截器可以帮助我们处理上述内容，请看官网的 Plugins 的片段, 内容不多 1 2 3 4 5 6 7 8 // 执行 Executor (update, query, flushStatements, commit, rollb

关于 Java String，这是面试的基础，但是还有很多童鞋不能说清楚，所以本文将简单而又透彻的说明一下那个让你迷惑的 String 在 Java 中，我们有两种方式创建一个字符串 1 2 String x = "abc"; String y = new String("abc"); 你常见也常写第一种，很少见第二种，但面试还总问这类问题，双引号和构造器两种形式创建字符串到底有什么差别呢？ 先来看例子 例子 1 1 2 3 4 String a = "abcd"; String b = "abcd"; System.out.println(a == b); // T

写在前面 上一篇文章这次走进并发的世界，请不要错过 给大家带了并发编程的开胃菜，接下来我们逐步上正餐，在吃正餐之前，我还要引用那首诗词: 「横看成岭侧成峰，远近高低各不同」，远看看轮廓，近看看细节，不断切换思维或视角来学习 远看并发，并发编程可以抽象成三个核心问题: 分工、同步/协作、互斥 如果你已经工作了，那么你一定听说过或者正在应用敏捷开发模式来交付日常的工作任务，我们就用你熟悉的流程来解释这三个核心问题 分工 将当前 Sprint 的 Story 拆分成「合适」大小的 Task，并且安排给「合适」的 Team Member 去完成 这里面用了两个「合适」，将 Story 拆分

写在前面 Java 有进阶，其名为并发，并发知识之大，一口吃不下。那好，请您多吃几口，又没说一顿吃完，细嚼慢咽才有味. 所有 Java 书籍都将并发编程放在其高级/进阶篇章中，其重要性不言而喻，学好并发也是自身走入高级行列的必备素质之一 并发/并行，进程/线程 这些概念总是显得过于抽象，因为这是与操作系统沟通用到的词汇，就像我们习惯了使用十进制算法，二进制和 16 进制就需要思维的切换；生活中，我们彼此总是不能互相理解，平静之后，我们知道要换位思考；程序的世界也一样，为了更好的理解问题，你也要站在操作系统的角度来思考问题，但当你尝试理解对方时，是违背自己认知习惯的，所以有些困难在所难免 生

话说异常 「欲渡黄河冰塞川，将登太行雪满天」，无论生活还是计算机世界难免发生异常，上一篇文章RESTful API 返回统一JSON数据格式 说明了统一返回的处理，这是请求一切正常的情形；这篇文章将说明如何统一处理异常，以及其背后的实现原理，老套路，先实现，后说明原理，有了上一篇文章的铺底，相信，理解这篇文章就驾轻就熟了 实现 新建业务异常 新建 BusinessException.class 类表示业务异常，注意这是一个 Runtime 异常 1 2 3 4 5 6 7 8 9 @Data @AllArgsConstructor public final class Busine

关于 Spring 的全局处理，我有两方面要说: 1. 统一数据返回格式 2. 统一异常处理 为了将两个问题说明清楚，将分两个章节分别说明，本章主要说第一点 有童鞋说，我们项目都做了这种处理，就是在每个 API 都单独工具类将返回值进行封装，但这种不够优雅；我想写最少的代码完成这件事，也许有童鞋说，加几个注解就解决问题了，说的没错，但这篇文章主要是为了说明为什么加了几个注解就解决问题了，目的是希望大家知其所以然。 为了更好的说明问题，本文先说明如何实现，然后再详细剖析实现原理(这很关键) 为什么要做统一数据返回格式 前后端分离是当今服务形式的主流，如何设计一个好的

写在前面 在一款应用的整个生命周期，我们都会谈及该应用的数据安全问题。用户的合法性与数据的可见性是数据安全中非常重要的一部分。但是，一方面，不同的应用对于数据的合法性和可见性要求的维度与粒度都有所区别；另一方面，以当前微服务、多服务的架构方式，如何共享Session，如何缓存认证和授权数据应对高并发访问都迫切需要我们解决。Shiro的出现让我们可以快速和简单的应对我们应用的数据安全问题 Shiro介绍 Shiro简介 这个官网解释不抽象，所以直接用官网解释：Apache Shiro™是一个强大且易用的 Java 安全框架，可以执行身份验证、授权、加密和会话管理等。基于 Shiro 的易于理解