原文链接：https://www.jianshu.com/p/63534c3baec3 转载请注明出处

1540361271922.png

从master直接切换到另一分支名(drpV2.0.24)的时候，出现游离状态，没有改动代码，只是想让HEAD从游离状态中恢复到正常分支上，但git checkout drpV2.0.24 并没有用...还是在游离状态...

解决方法

1. git branch -v 查看当前领先多少

 

1540361405219.png

a9031fb 指向的是`drpV2.0.24`的最后一次提交

1. 新建一个 temp 分支，把当前提交的代码放到整个分支

 

1540361524207.png

 

1540361605823.png

1. checkout 要回到的那个分支，这里是 drpV2.0.24

 

1540361658981.png

发现不再是游离状态

• —软件人才免语言低担保 赴美带薪读研！—

原文地址：https://www.jianshu.com/p/2b17c3879879

idea方法注释，系统默认的只能获取到参数，无法获取返回值，如下：

/**
     * 
     * @param id
     * @param type
     * @return
     */
    public static String getName(Long id, int type) {
        return null;
    }

使用Eclipse时我们生成注释的习惯是/**+Enter，这里我们也按照这种习惯来设置IDEA的方法注释

1. File-->Settings-->Editor-->Live Templates

 

1539077097651.png

1.1 新建Template Group: 命名为 MethodBingtai

 

1539077305313.png

1.2 在MethodBingtai下新建Live Template，命名为*

 

1539077602137.png

 

LiveTemplate.png

因为IDEA生成注释的默认方式是：/* +模板名+快捷键（比如若设置模板名为add快捷键用Tab，则生成方式为/*add+Tab），如果不采用这样的生成方式IDEA中没有内容的方法将不可用，例如获取方法参数的methodParameters(）、获取方法返回值的methodReturnType(）

1.3 设置注释的快捷键

 

TIM截图20181009193521.png

1.4 设置模板

模板内容如下：

*
 * 功能描述: <br>
 * 〈$END$〉
 * @Param: $param$
 * @Return: $return$
 * @Author: $user$
 * @Date: $DATE$ $TIME$
 */

注意 第一行，只有一个* 而不是/*

在设置参数名时必须用$参数名$的方式，否则1.5中读取不到你设置的参数名

1.5 设置参数的获取方式

选择右侧的Edit variables按钮

 

1539078565190.png

选择每个参数对应的获取方法（在下拉选择框中选择即可），网上有很多教程说获取param时使用脚本的方式，我试过使用脚本的方式不仅麻烦而且只能在方法内部使用注释时才能获取到参数

 

1539078839738.png

选择应用场景：勾选Java

 

1539078870502.png

注意 点击模板页面最下方的警告，来设置将模板应用于那些场景，一般选择Java即可（如果曾经修改过，则显示为Change而不是Define）

再次选择右侧的Edit variables按钮，下拉框就有选项了；如下图，选中对应的Expression，点击OK

 

1539079048193.png

2. 效果

创建方法，在方法上一行，输入 /** ，然后 回车

 

1539084053764.png

参考: IDEA类和方法注释模板设置

• —软件人才免语言低担保 赴美带薪读研！—

想要成为架构师，对技术的深度和广度都有很高的要求，本文列举出成为一个架构师必备的技能和学习路线。
对于学习途径有疑惑或苦恼，或者有优秀资料可以提供的同学，可加微信，共同交流学习 

wx_qcode.jpg

1. 阅读源码

说到阅读源码，可能很多同学都尝试过去阅读一些开源框架的源码，但是很难找到一个入口点；即便找到入口点，又会觉得源码中好绕，看着看着把自己都看晕了。其实，阅读源码是需要基础的。开源框架的源码中都使用了大量的设计模式，所以在阅读源码之前，我们首先要熟悉常见的设计模式

1.1 常用设计模式

• Proxy 代理模式
• Factory 工厂模式
  • 简单工厂模式
  • 工厂方法模式
  • 抽象工厂模式
• Singleton 单例模式
• Delegate 委派模式
• Strategy 策略模式
• Prototype 原型模式
• Template 模板模式

推荐书籍
《大话设计模式》 程杰 著

1.2 Spring源码走读

Spring 源码主要又分为一下几大块：

1.2.1 spring-beans包

• 接口示例化
• 代理Bean操作

1.2.2 spring-context包

• IOC容器设计原理及高级特性
• AOP设计原理
• FactoryBean与BeanFactory

1.2.3 spring-tx包

• 声明式事务底层原理
• Spring事务处理机制
• 事务的传播与监控
• 基于SpringJDBC手写ORM框架

1.2.4 spring-webmvc

• MVC原理介绍
• 与IOC容器整合原理
• HandlerMapping实现原理
• HandlerAdapter实现原理
• ViewResolver实现原理
• Controller实现原理
• 动态参数匹配原理
• SpringMVC与Struts2对比分析
• 手写实现SpringMVC框架

1.2.5 Spring5新特性

• Spring 5.x的兼容性
• 分析自带通用日志框架
• 多序列化数据格式绑定API
• 函数式风格的ApplicationContext
• Kotlin表达式的支持
• WebFlux模块介绍
• Testing改进

阅读指引
spring源码学习 - 一个简单bean的实例化过程
spring源码学习 - 注解bean的解析注册过程

1.3 MyBatis

• 代码自动生成器：Generator
• MyBatis下1对多，多对多嵌套结果、嵌套查询
• 一级缓存、二级缓存使用场景及选择策略
• MyBatis与Spring集成spring-mybatis.jar分析
• Spring集成下的SqlSession与Mapper
• MyBatis的事务
• 分析MyBatis的动态代理的真正实现
• 一步一步手写实现MyBatis 1.0到2.0

2. 分布式架构

2.1 漫谈分布式架构

• 初识分布式架构及意义
• 如何把应用从单机扩展分布式
• 大型分布式架构演进过程
• 构建分布式架构最重要因素
  • CDN加速静态文件访问
  • 分布式存储
  • 分布式搜索引擎
  • 应用发布与监控
  • 应用容灾及机房规划
  • 系统动态扩容
• 分布式架构设计
  • 主流架构模型-SOA架构和微服务架构
  • 领域驱动设计及业务驱动划分
  • 分布式架构的基本理论CAP、BASE以及其应用
  • 什么是分布式架构下的高可用设计
  • 分布式架构下的可伸缩设计
  • 构建高性能的分布式架构

2.2 分布式架构策略-分而治之

• 从简到难，从网络通信探究分布式通信的原理
• 基于消息方式的系统间通信
• 理解通信协议传输过程中的序列化和反序列化机制
• 基于框架的RPC通信技术
  • WebService/Apache CXF
  • RMI/Spring RMI
  • Hessian
• 传统RPC技术在大型分布式架构下面临的问题
• 分布式架构下的RPC解决方案
• 分布式系统的基石-Zookeeper、
  • 从0开始搭建3个节点的zookeeper集群
  • 深入分析Zookeeper在disconf配置中心的应用
  • 基于Zookeeper的分布式锁解决方案
  • Zookeeper Watcher 核心机制深入源码分析
  • Zookeeper集群升级、迁移
  • 基于Zookeeper实现分布式服务器动态上下线感知
  • 深入分析Zookeeper Zab协议及选举机制源码解读
• 使用dubbo对单一应用服务化改造
  • dubbo管理中心及监控平台安装部署
  • dubbo分布式服务模块划分(领域驱动)
  • 基于dubbo分布式系统架构实践
  • dubbo负载均衡策略分析
  • dubbo服务调试之服务只订阅及服务只注册配置
  • dubbo服务接口的设计原则(实战经验分享)
  • dubbo设计原理及源码分析
  • 基于dubbo构建大型分布式电商平台实战雏形
  • dubbo容错机制及高扩展性分析

2.3 分布式架构-中间件

2.3.1 消息中间件(分布式消息通信)

2.3.1.1 消息中间件在分布式框架中的应用

2.3.1.2 消息中间件ActiveMQ

• ActiveMQ高可用集群企业级部署方案
• ActiveMQ P2P及PUB/SUB模型详解
• ActiveMQ消息确认及重发策略
• ActiveMQ基于Spring完成分布式消息队列实战

2.3.1.3 消息中间件Kafka

• Kafka基于Zookeeper搭建高可用集群实践
• Kafka消息处理过程剖析
• Java客户端实现Kafka生产者与消费者实例
• Kafka的副本机制及选举原理剖析
• 基于Kafka实现应用日志实时上报统计分析

2.3.1.4 消息中间件RabbitMQ

• 初步认识RabbitMQ及高可用集群部署
• 详解RabbitMQ消息分发机制及主题消息分发
• RabbitMQ消息路由机制分析
• RabbitMQ消息确认机制

2.3.2 分布式缓存(Redis)

• 从入门到精通，Redis的数据结构分析
• Redis主从复制原理及无磁盘复制分析
• Redis管道模式详解
• Redis缓存与数据库一致性问题解决方案
• 基于Redis实现分布式锁
• 图解Redis中的AOF和RDB持久化策略的原理
• Redis读写分离架构实践
• Redis烧饼架构及数据丢失问题分析
• Redis Cluster 数据分布算法之Hash slot
• 使用Redis常见问题及性能优化思路
• Redis高可用及高伸缩架构实战
• 缓存击穿、缓存雪崩预防策略
• Redis批量查询优化
• Redis高性能集群之twemproxy or codis

2.3.3 数据存储

2.3.3.1 非结构化数据NoSQL

• NoSQL简介及MongoDB基本概念
• MongoDB支持的数据类型分析
• MongoDB可视化客户端及Java API实践
• 手写基于MongoDB的ORM框架
• MongoDB企业级集群解决方案
• MongoDB聚合、索引及基本执行命令
• MongoDB数据分析 、转存及恢复策略

2.3.3.2 mysql数据库

• MySQL主从符合及读写分离实战
• MySQL + keepalived实现双主高可用方案实践
• MySQL 高性能解决方案之分库分表

2.3.3.3 分库分表中间件(Mycat)

• 初识数据库中间件Mycat
• 基于Mycat实现mysql数据库读写分离
• 基于Mycat实战之数据库切分策略剖析
• Mycat全局表、ER表、分片策略分析

2.3.4 后台服务

• 基于OpenResty部署应用层Nginx以及Nginx+lua实践
• Nginx反向代理服务器及负载均衡服务配置实战
• 利用keepalived + Nginx实践Nginx高可用方案
• 基于Nginx实现访问控制、连接限制
• Nginx动静分离实战
• Nginx Location、Rewrite等语法配置及原理分析
• Nginx提供https服务
• 基于Nginx+lua完成访问流量实时上报kafka的实战

2.3.5 高性能的NIO框架(Netty)

• IO的基本概念、NIO、AIO、BIO深入分析
• NIO的核心设计思想
• Netty产生的背景及应用场景分析
• 基于Netty实现高性能IM聊天工具
• 基于Netty实现Dubbo多协议通信支持
• Netty无锁化串行设计及高并发处理机制
• 手写实现多协议RPC框架

2.4 分布式解决方案

• 分布式全局ID生成方案
• session跨域共享及企业级单点登录解决方案实战
• 分布式事务解决方案实战
• 高并发下的服务降级、限流
• 基于分布式架构下分布式锁的解决方案
• 分布式架构下实现分布式定时调度

推荐书籍
《大型网站系统与Java中间件实践》曾宪杰 著
《分布式服务框架原理与实践》 李林峰 著

3. 微服务架构

3.1 微框架(Spring Boot)

• Spring Boot与微服务之间的关系
• Spring Boot热部署实战
• 核心组件之starter、actuator、auto-configuration、cli
• Spring Boot集成MyBatis实现多数据源路由实战
• Spring Boot集成Dubbo实战
• Spring Boot 集成Redis实战
• Spring Boot集成Swagger2 构建API管理及测试体系
• Spring Boot实现多环境配置动态解析

3.2 Spring Cloud

• Eureka注册中心
• Ribbon集成REST实现负载均衡
• Fegion声明式服务调用
• Hystrix服务熔断降级方式
• Zuul实现微服务网关
• Config分布式统一配置中心
• Sleuth调用链路跟踪
• BUS消息总线
• 基于Hystrix实现接口降级实战
• Spring Boot集成Spring Cloud实现统一整合分离

3.3 Docker虚拟化

• 了解Docker的镜像、仓库、容器
• Dockerfile构建LNMP环境部署个人博客wordpress
• Docker Compose构建LNMP环境部署个人博客wordpress
• Docker网络组成、路由互联、openvswitch
• 基于swarm构建Docker集群实战
• Kubernetes简介

3.4 漫谈微服务架构

• SOA架构和微服务架构之间的区别与联系
• 如何设计微服务及其设计原则
• 解惑Spring Boot流行因素及能够解决什么问题
• 什么是Spring Cloud，为何要选择Spring Cloud
• 基于全局分析Spring Cloud各个组件所解决的问题

推荐书籍
《Spring Cloud与Docker微服务架构实战》周立 著

4. 并发编程

4.1 Java 内存模型(JMM)

• 线程通信
• 消息传递

4.2 内存模型

• 指令重排序
• 顺序一致性
• happens-before
• as-if-serial

4.3 synchronized

• 同步、重量级锁
• synchronized原理
• 锁优化
  • 自旋锁
  • 轻量级锁
  • 重量级锁
  • 偏向锁

4.4 volatile

• volatile 实现机制
• 内存语义
• 内存模型

4.5 DCL(Double Check Lock)

• 单例模式
• DCL(双检锁)
• 解决方案

4.6 并发基础

• AQS
  • AbstractQueuedSynchronizer同步器
  • CLH同步队列
  • 同步状态的获取和释放
  • 线程阻塞和唤醒
• CAS
  • Compare And Swap
  • 缺陷

4.7 锁

• ReentrantLoak 可重入锁
• ReentrantLockReadWriteLock 可重入读写锁
• Condition

4.8 并发工具类

• CyclicBarrier
• CountDownLatch
• Semphore

4.9 并发集合

• ConcurrentHashMap
• ConcurrentLinkedQueue

4.10 原子操作

• 基本类型
  • AtomicBoolean
  • AtomicInteger
  • AtomicLong
• 数组
  • AtomicIntegerArray
  • AtomicLongArray
  • AtomicReferenceArray
• 引用类型
  • AtomicReference
  • AtomicReferenceFieldUpdater

4.11 线程池

• Executor
• ThreadPoolExecutor
• CallableFuture
• ScheduledExecutorService

4.12 其他

• TheadLocal
• Fork/Join

推荐书籍
《深入理解Java虚拟机》周志明 著
《实战Java高并发程序设计》 葛一鸣 郭超 编著 墙裂推荐
《Java并发编程实战》Brian Goetz/ Tim Peierls/ Joshua Bloch/ Joseph Bowbeer/ David Holmes/ Doug Lea 著 董云兰等译

5. 性能优化

5.1 理解性能优化

• 性能基准
• 性能优化到底是什么
• 衡量维度

5.2 JVM调优

• 知其然，知其所以然
• 什么是JVM运行时数据区
• 什么是JVM内存模型JMM
• 各种垃圾回收器使用场景(throughput\CMS)
• 理解GC日志，从日志看端倪
• 实战MAT分析dump文件

5.3 Tomcat调优篇

• 分析Tomcat线程模型
• Tomcat系统参数认识及调优
• 基准测试

5.4 MySQL调优

• 理解MySQL低层B+Tree机制
• SQL执行计划详解
• 索引优化详解
• SQL语句优化

6. 团队协作效率

6.1 Maven

• 生成可执行jar、理解Scope生产呢过最精确的jar
• 解决类冲突、包依赖 NoClassDefFoundError问题定位及解决
• 全面理解Maven的Lifecycle\Phase\Goal
• 架构师必备之Maven生成Archetype
• Maven流行插件实战、手写自己的插件
• Nexus使用、上传、配置
• 对比Gradle

6.2 Jenkins

持续集成，一次build解决所有手动工作

6.3 Sonar

减少人为疏漏，静态代码检查，让你的代码更健壮

6.4 Git

• 什么是git以及git的工作原理
• git常用命令best practise(避坑教学)
• git冲突怎么引起的，如何解决
• 架构师职责：git flow规范团队git使用规程
• 团队案例分享(买不到才是最贵的)

7. 项目实战

未完待续...

其他书籍推荐：
《深入分析Java Web技术内幕》
《Java编程思想》
《Effective Java》
《重构 改善既有代码结构》
《高性能MySQL》

 

 

• —软件人才免语言低担保 赴美带薪读研！—

原文地址：https://www.jianshu.com/p/deee6abf0b72 转载请注明出处

TCP: 传输控制协议（英语：Transmission Control Protocol，缩写为TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。

UDP:用户数据报协议（英语：User Datagram Protocol，缩写为UDP），又称使用者资料包协定，是一个简单的面向数据报的传输层协议，正式规范为RFC 768。

共同点

• 传输层协议

不同点

• UDP 继承 IP 的特性，不保证不丢失，不保证按顺序到达。TCP 就是提供可靠的数据，无差错、不丢失、不重复、按循序到达。

• TCP提供有保证的数据传输，而UDP不提供

  这意味着TCP有一个特殊的机制来确保数据安全的不出错的从一个端点传到另一个端点，而UDP不提供任何这样的保证。

• TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性， 但TCP的三次握手在最低限度上（实际上也很大程度上保证了）保证了连接的可靠性；

• UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号， 发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议

也正由于上面的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。

所以采用TCP传输协议的MSN比采用UDP的QQ传输文件慢

但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证， 比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的

• UDP 是数据格式基于数据报，一个一个的发，一个一个的收。TCP 是面向字节流，发送的是一个流数据。

• UDP 是不处理堵塞，应用需要发，就会发送。TCP 还拥有堵塞控制，TCP 会根据网络环境调整发包的频率。

• UDP 支持多播和广播

TCP、UDP对比

 TCP和UDP协议的一些应用

image

引申

TCP三次握手

TCP 是面向连接的，数据通信之前必须要建立连接，这个连接可以是 1 对多。

TCP 三次握手的过程

 

image

上图展示三次握手的流程图，文字描述过程如下： 客户端和服务端从 CLOSED 的状态变成在线状态。服务端需要处于 LISTEN. 1、客户端向服务端发起一个连接。报文中包含了： SYN = 1, 「序列号」的值， 发送之后客服端进入到 SYN-SENT 状态。

2、服务端接收到 SYN 和 序列号信息后，需要对这个报文进行的确认。服务端收到客户端发送过来的「序列号」的值，服务端会返回一个「确认号」的值（序列号+1）。同时返回 SYN = 1 表示还在同步阶段。 ACK = 1 表示确认号有意义。 序列号：表示服务端的序列号 y。 确认号：针对客户端发起连接的一个确认号。 服务端发送之后，进入到 SYN-RCVD 状态。

3、客户端接收到服务端返回的数据，使得客户端这一边的相关通信建立，并且同步了相关序列号和确认号的数值，但是服务端还没有接收到客户端回复的确认号。所以客户端需要再发送一个数据到服务端，主要包含： ACK = 1，这是确认号的数据有意义。 SYN = 0 序列号已经同步完成，不需要再同步序列号。 序列号：因为 SYN 已经不是第一次同步序列号的信息了。这个时候的序列号，就表示的是一个单纯的基于序列号最新的数据包的序列号。其值为：x+1。 确认号：返回服务端序列号 y 的确认号，为 y+1。 发送这个值之后，客户端进入到 ESTABLISHED 状态，服务端接受到这个值之后也进入到ESTABLISHED 状态。然后就可以开始传递数据通信了。

至此三次握手已经完成。

通俗易懂的描述

TCP 为什么进行是三次握手？

为什么 TCP 需要进行三次握手，这个问题很多人的解释都引用了

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。—— 谢希仁的《计算机网络》

首先我们需要明白三次握手的意义在于什么，也就是说三次握手需要达到的一个目的是什么， 简单来说，其实是为了同步序列号和确认号的相关信息，而序列号和确认号又是保障数据的正确性以及窗口滑动机制的最基本的根据。所以我最需要明白的可能还是为什么要同步序列号就是为什么要三次握手：（举个例子来说明） 如果 A 给 B发送一个数据包，这个包由于网络的原因，很久才到 B 端，而这段时间，A 和 B 已经断开，并且重新建立了连接关系。没有相关同步序列号和确认号，B 端认为这个数据还是认为 A 这个时候要发给我的，但是其实这个数据上一次传输的数据，相当于这次传输的数据中插入了其他的数据，那么就会导致这次的数据出现异常。

为什么不是两次

对于 A 来看说，两次实现了信息一来一回，但是 TCP 的数据的可靠性，如果要实现对于 B 来说的信息的一来一回，那么第三次是一定要存在的。对两端的数据一来一回才是建立可靠连接的基本要求。

为什么不是四次

理论上其实这个同步序列号和确认号的过程，大于三次也不是没有的，应该说几十次上百次都是可以的，但是三次握手的过程已经实现了序号数据同步，在进行太多次的序号同步，已经没有意义。无故浪费宽带。

TCP 四次挥手

当通信完成，当然需要能够进行连接断开。

TCP 四层挥手的过程：

 

image

1、任意一段（ A 端）发出一条 FIN 的数据。数据包含： FIN = 1, 序列号 A 端发出这个数据之后，进入到 FIN - WAIT -1 的状态，等待 B 端的回复.

2、B 收到 A 端的 FIN 的信息就回复一个数据，表示已经知道 A 端请求断开连接这个事情了。此时 B 端进入到 CLOSED - WAIT 的状态。A 端接收到这个数据进入到 FIN - WAIT -2 的状态。 数据中包含 ： ACK = 1 确认号

3、B 端给 A 端发起一次 FIN 的数据。请求结束连接，发送完成之后 B 端进入到 LAST - ACK 状态。发送的数据包含： FIN = 1; 序列号 ACK = 1; 确认号

4、 A 端接收到这个 B 端发送的 FIN 数据进入到 TIME- WAIT 状态，同时回复 B 端，已经接收到了 FIN 数据。回复的包中包含： ACK = 1; 确认号

为什么需要设置一个 TIME-WAIT 的时间

这个文章讲的特别好

一、保证TCP协议的全双工连接能够可靠关闭 先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

二、保证这次连接的重复数据段从网络中消失 再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

TCP 为什么进行是四次挥手？

断开比连接更复杂，比较直接的理解是资源回收比资源分配会更麻烦。使得所有资源能够有效并且不产生错误的情况下释放。

三次握手的本质是：将“四次握手”中的第二次、第三次握手合为一次，因为“四次握手”中的第二次、第三次握手都是由B向A传递报文，而且这两次发送报文的目的允许这两次报文合并为一次。那么，TCP四次挥手中的第二次、第三次挥手，能否也能合为一次呢？

答案是否定的。将TCP四次挥手中的第二次、第三次挥手，合为一次。也就是将CLOSE_WAIT状态的停留时间变为0。然而，B之所以存在CLOSE_WAIT状态，是因为B可能还存在着需要发送给A但是未发送的数据，如果存在着这些数据，那么这个状态的时间，就是用来发送这些数据的，所以，TCP四次挥手中的第二次、第三次挥手无法合并为一次。所以，也就无法实现“TCP三次挥手”。
参考
TCP、UDP、Socket、HTTP你不知道的故事
UDP 的模样和你想的是否一样
跟着动画学习 TCP 三次握手和四次挥手
TCP、UDP以及TCP滑窗，它们的区别

• —软件人才免语言低担保 赴美带薪读研！—

原文地址：https://www.jianshu.com/p/173009ccfd7b 转载请注明出处

短连接

连接->传输数据->关闭连接

HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。

长连接

连接->传输数据->保持连接 -> 传输数据-> ... ->关闭连接。

长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

http的长连接

HTTP也可以建立长连接的，使用Connection:keep-alive，HTTP 1.1默认进行持久连接。

HTTP1.1和HTTP1.0相比较而言，最大的区别就是增加了持久连接支持(貌似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。

每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，每次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。

所以并发量大，但每个用户无需频繁操作情况下需用短连接好。

补充与扩展

通俗点讲，短连接就是一次TCP请求得到结果后,连接马上结束.而长连接并不马上断开,而一直保持着,直到长连接TIMEOUT(具体程序都有相关参数说明).长连接可以避免不断的进行TCP三次握手和四次挥手.

长连接(keepalive)是需要靠双方不断的发送探测包来维持的,keepalive期间服务端和客户端的TCP连接状态是ESTABLISHED。

• —软件人才免语言低担保 赴美带薪读研！—

简介

Java为数据结构中的映射定义了一个接口java.util.Map，此接口主要有四个常用的实现类，分别是HashMap、Hashtable、LinkedHashMap和TreeMap，类继承关系如下图所示：

 

image.png

下面针对各个实现类的特点做一些说明：

1. HashMap:根据键的hashCode值存储数据，直接定位到它的值，因而具有很快的访问速度，但遍历顺序却是不确定的。 HashMap最多只允许一条记录的键为null，允许多条记录的值为null。HashMap非线程安全，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要满足线程安全，可以用 Collections的synchronizedMap方法使HashMap具有线程安全的能力，或者使用ConcurrentHashMap。

2. HashTable:遗留类，很多映射的常用功能与HashMap类似，不同的是它承自Dictionary类，并且是线程安全的，任一时间只有一个线程能写Hashtable，并发性不如ConcurrentHashMap，因为ConcurrentHashMap引入了分段锁。Hashtable不建议在新代码中使用，不需要线程安全的场合可以用HashMap替换，需要线程安全的场合可以用ConcurrentHashMap替换。

3. LinkedHashMap:HashMap的一个子类，保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的，也可以在构造时带参数，按照访问次序排序。

4. TreeMap:实现SortedMap接口，能够把它保存的记录根据键排序，默认是按键值的升序排序，也可以指定排序的比较器，当用Iterator遍历TreeMap时，得到的记录是排过序的。如果使用排序的映射，建议使用TreeMap。在使用TreeMap时，key必须实现Comparable接口或者在构造TreeMap传入自定义的Comparator，否则会在运行时抛出java.lang.ClassCastException类型的异常。

   注意：对于上述四种Map类型的类，要求映射中的key是不可变对象。不可变对象是该对象在创建后它的哈希值不会被改变。如果对象的哈希值发生变化，Map对象很可能就定位不到映射的位置了。

通过上面的比较，我们知道了HashMap是Java的Map家族中一个普通成员，鉴于它可以满足大多数场景的使用条件，所以是使用频度最高的一个。下文我们主要结合源码，从存储结构、常用方法分析、扩容以及安全性等方面深入讲解HashMap的工作原理。

内部实现

搞清楚HashMap，首先需要知道HashMap是什么，即它的存储结构-字段；其次弄明白它能干什么，即它的功能实现-方法。下面我们针对这两个方面详细展开讲解。

存储结构-字段

从结构实现来讲，HashMap是数组+链表+红黑树（JDK1.8增加了红黑树部分）实现的，如下如所示。

 

image

1. 数据底层存储的是Node节点，Node是HashMap的一个内部类，实现了Map.Entry接口，本质是就是一个映射(键值对)。上图中的每个黑色圆点就是一个Node对象。

2. 存储方式的优点：HashMap就是使用哈希表来存储的。哈希表为解决冲突，可以采用开放地址法和链地址法等来解决问题，Java中HashMap采用了链地址法。链地址法，简单来说，就是数组加链表的结合。在每个数组元素上都一个链表结构，当数据被Hash后，得到数组下标，把数据放在对应下标元素的链表上。

static final float DEFAULT_LOAD_FACTOR = 0.75f; // 负载因子
static final int TREEIFY_THRESHOLD = 8; // 所能容纳的最大数据量的Node(键值对)个数
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 HashMap默认容量 16

在JDK1.8版本中，对数据结构做了进一步的优化，引入了红黑树。而当链表长度太长（默认超过8）时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能

功能实现

HashMap的内部功能实现很多，本文主要从根据key获取哈希桶数组索引位置、put方法的详细执行、扩容过程三个具有代表性的点深入展开讲解。

1. 确定哈希桶数组索引位置

不管增加、删除、查找键值对，定位到哈希桶数组的位置都是很关键的第一步。前面说过HashMap的数据结构是数组和链表的结合，所以我们当然希望这个HashMap里面的元素位置尽量分布均匀些，尽量使得每个位置上的元素数量只有一个，那么当我们用hash算法求得这个位置的时候，马上就可以知道对应位置的元素就是我们要的，不用遍历链表，大大优化了查询的效率。HashMap定位数组索引位置，直接决定了hash方法的离散性能。先看看源码的实现(方法一+方法二):

方法一：
static final int hash(Object key) {   //jdk1.8 & jdk1.7
 int h;
 // h = key.hashCode() 为第一步 取hashCode值
 // h ^ (h >>> 16)  为第二步 高位参与运算
 return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
方法二：
static int indexFor(int h, int length) {  //jdk1.7的源码，jdk1.8没有这个方法，但是实现原理一样的
 return h & (length-1);  //第三步 取模运算
}

这里的Hash算法本质上就是三步：取key的hashCode值、高位运算、取模运算。

对于任意给定的对象，只要它的hashCode()返回值相同，那么程序调用方法一所计算得到的Hash码值总是相同的。我们首先想到的就是把hash值对数组长度取模运算，这样一来，元素的分布相对来说是比较均匀的。但是，模运算的消耗还是比较大的，在HashMap中是这样做的：调用方法二来计算该对象应该保存在table数组的哪个索引处。

这个方法非常巧妙，它通过h & (table.length -1)来得到该对象的保存位，而HashMap底层数组的长度总是2的n次方，这是HashMap在速度上的优化。当length总是2的n次方时，h& (length-1)运算等价于对length取模，也就是h%length，但是&比%具有更高的效率。

在JDK1.8的实现中，优化了高位运算的算法，通过hashCode()的高16位异或低16位实现的：(h = k.hashCode()) ^ (h >>> 16)，主要是从速度、功效、质量来考虑的，这么做可以在数组table的length比较小的时候，也能保证考虑到高低Bit都参与到Hash的计算中，同时不会有太大的开销。

下面举例说明下，n为table的长度。

 

image

2. 分析HashMap的put方法

HashMap的put方法执行过程可以通过下图来理解，自己有兴趣可以去对比源码更清楚地研究学习。

 

image

JDK1.8HashMap的put方法源码如下:

1 public V put(K key, V value) {
 2     // 对key的hashCode()做hash
 3     return putVal(hash(key), key, value, false, true);
 4 }
 5 
 6 final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
 7                boolean evict) {
 8     Node<K,V>[] tab; Node<K,V> p; int n, i;
 9     // 步骤①：tab为空则创建
10     if ((tab = table) == null || (n = tab.length) == 0)
11         n = (tab = resize()).length;
12     // 步骤②：计算index，并对null做处理 
13     if ((p = tab[i = (n - 1) & hash]) == null) 
14         tab[i] = newNode(hash, key, value, null);
15     else {
16         Node<K,V> e; K k;
17         // 步骤③：节点key存在，直接覆盖value
18         if (p.hash == hash &&
19             ((k = p.key) == key || (key != null && key.equals(k))))
20             e = p;
21         // 步骤④：判断该链为红黑树
22         else if (p instanceof TreeNode)
23             e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
24         // 步骤⑤：该链为链表
25         else {
26             for (int binCount = 0; ; ++binCount) {
27                 if ((e = p.next) == null) {
28                     p.next = newNode(hash, key,value,null);
 //链表长度大于8转换为红黑树进行处理
29                     if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st  
30                         treeifyBin(tab, hash);
31                     break;
32                 }
 // key已经存在直接覆盖value
33                 if (e.hash == hash &&
34                     ((k = e.key) == key || (key != null && key.equals(k)))) 
35                            break;
36                 p = e;
37             }
38         }
39 
40         if (e != null) { // existing mapping for key
41             V oldValue = e.value;
42             if (!onlyIfAbsent || oldValue == null)
43                 e.value = value;
44             afterNodeAccess(e);
45             return oldValue;
46         }
47     }
​
48     ++modCount;
49     // 步骤⑥：超过最大容量 就扩容
50     if (++size > threshold)
51         resize();
52     afterNodeInsertion(evict);
53     return null;
54 }

①.判断键值对数组table[i]是否为空或为null，否则执行resize()进行扩容；

②.根据键值key计算hash值得到插入的数组索引i，如果table[i]==null，直接新建节点添加，转向⑥，如果table[i]不为空，转向③；

③.判断table[i]的首个元素是否和key一样，如果相同直接覆盖value，否则转向④，这里的相同指的是hashCode以及equals；

④.判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对，否则转向⑤；

⑤.遍历table[i]，判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操作，否则进行链表的插入操作；遍历过程中若发现key已经存在直接覆盖value即可；

⑥.插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold，如果超过，进行扩容。

3. 扩容机制

扩容(resize)就是重新计算容量，向HashMap对象里不停的添加元素，而HashMap对象内部的数组无法装载更多的元素时，对象就需要扩大数组的长度，以便能装入更多的元素。当然Java里的数组是无法自动扩容的，方法是使用一个新的数组代替已有的容量小的数组，就像我们用一个小桶装水，如果想装更多的水，就得换大水桶。

我们分析下resize的源码，鉴于JDK1.8融入了红黑树，较复杂，为了便于理解我们仍然使用JDK1.7的代码，好理解一些，本质上区别不大，具体区别后文再说。

1 void resize(int newCapacity) {   //传入新的容量
 2     Entry[] oldTable = table;    //引用扩容前的Entry数组
 3     int oldCapacity = oldTable.length; 
 4     if (oldCapacity == MAXIMUM_CAPACITY) {  //扩容前的数组大小如果已经达到最大(2^30)了
 5         threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1)，这样以后就不会扩容了
 6         return;
 7     }
 8
 9     Entry[] newTable = new Entry[newCapacity];  //初始化一个新的Entry数组
10     transfer(newTable);                         //！！将数据转移到新的Entry数组里
11     table = newTable;                           //HashMap的table属性引用新的Entry数组
12     threshold = (int)(newCapacity * loadFactor);//修改阈值
13 }

这里就是使用一个容量更大的数组来代替已有的容量小的数组，transfer()方法将原有Entry数组的元素拷贝到新的Entry数组里。

 1 void transfer(Entry[] newTable) {
 2     Entry[] src = table;                   //src引用了旧的Entry数组
 3     int newCapacity = newTable.length;
 4     for (int j = 0; j < src.length; j++) { //遍历旧的Entry数组
 5         Entry<K,V> e = src[j];             //取得旧Entry数组的每个元素
 6         if (e != null) {
 7             src[j] = null;//释放旧Entry数组的对象引用（for循环后，旧的Entry数组不再引用任何对象）
 8             do {
 9                 Entry<K,V> next = e.next;
10                 int i = indexFor(e.hash, newCapacity); //！！重新计算每个元素在数组中的位置
11                 e.next = newTable[i]; //标记[1]
12                 newTable[i] = e;      //将元素放在数组上
13                 e = next;             //访问下一个Entry链上的元素
14             } while (e != null);
15         }
16     }
17 }

newTable[i]的引用赋给了e.next，也就是使用了单链表的头插入方式，同一位置上新元素总会被放在链表的头部位置；这样先放在一个索引上的元素终会被放到Entry链的尾部(如果发生了hash冲突的话），这一点和Jdk1.8有区别，下文详解。在旧数组中同一条Entry链上的元素，通过重新计算索引位置后，有可能被放到了新数组的不同位置上。

下面我们讲解下JDK1.8做了哪些优化。经过观测可以发现，我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。看下图可以明白这句话的意思，n为table的长度，图（a）表示扩容前的key1和key2两种key确定索引位置的示例，图（b）表示扩容后key1和key2两种key确定索引位置的示例，其中hash1是key1对应的哈希与高位运算结果。

 

image

元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：

 

image

因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”，可以看看下图为16扩充为32的resize示意图：

 

image

这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。有兴趣的同学可以研究下JDK1.8的resize源码，写的很赞，如下:

1 final Node<K,V>[] resize() {
 2     Node<K,V>[] oldTab = table;
 3     int oldCap = (oldTab == null) ? 0 : oldTab.length;
 4     int oldThr = threshold;
 5     int newCap, newThr = 0;
 6     if (oldCap > 0) {
 7         // 超过最大值就不再扩充了，就只好随你碰撞去吧
 8         if (oldCap >= MAXIMUM_CAPACITY) {
 9             threshold = Integer.MAX_VALUE;
10             return oldTab;
11         }
12         // 没超过最大值，就扩充为原来的2倍
13         else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
14                  oldCap >= DEFAULT_INITIAL_CAPACITY)
15             newThr = oldThr << 1; // double threshold
16     }
17     else if (oldThr > 0) // initial capacity was placed in threshold
18         newCap = oldThr;
19     else {               // zero initial threshold signifies using defaults
20         newCap = DEFAULT_INITIAL_CAPACITY;
21         newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
22     }
23     // 计算新的resize上限
24     if (newThr == 0) {
25 
26         float ft = (float)newCap * loadFactor;
27         newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
28                   (int)ft : Integer.MAX_VALUE);
29     }
30     threshold = newThr;
31     @SuppressWarnings({"rawtypes"，"unchecked"})
32         Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
33     table = newTab;
34     if (oldTab != null) {
35         // 把每个bucket都移动到新的buckets中
36         for (int j = 0; j < oldCap; ++j) {
37             Node<K,V> e;
38             if ((e = oldTab[j]) != null) {
39                 oldTab[j] = null;
40                 if (e.next == null)
41                     newTab[e.hash & (newCap - 1)] = e;
42                 else if (e instanceof TreeNode)
43                     ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
44                 else { // 链表优化重hash的代码块
45                     Node<K,V> loHead = null, loTail = null;
46                     Node<K,V> hiHead = null, hiTail = null;
47                     Node<K,V> next;
48                     do {
49                         next = e.next;
50                         // 原索引
51                         if ((e.hash & oldCap) == 0) {
52                             if (loTail == null)
53                                 loHead = e;
54                             else
55                                 loTail.next = e;
56                             loTail = e;
57                         }
58                         // 原索引+oldCap
59                         else {
60                             if (hiTail == null)
61                                 hiHead = e;
62                             else
63                                 hiTail.next = e;
64                             hiTail = e;
65                         }
66                     } while ((e = next) != null);
67                     // 原索引放到bucket里
68                     if (loTail != null) {
69                         loTail.next = null;
70                         newTab[j] = loHead;
71                     }
72                     // 原索引+oldCap放到bucket里
73                     if (hiTail != null) {
74                         hiTail.next = null;
75                         newTab[j + oldCap] = hiHead;
76                     }
77                 }
78             }
79         }
80     }
81     return newTab;
82 }

线程安全性

线程不安全的，在多线程场景下，使用线程安全的ConcurrentHashMap

小结

(1) 扩容是一个特别耗性能的操作，所以当程序员在使用HashMap的时候，估算map的大小，初始化的时候给一个大致的数值，避免map进行频繁的扩容。

(2) 负载因子是可以修改的，也可以大于1，但是建议不要轻易修改，除非情况非常特殊。

(3) HashMap是线程不安全的，不要在并发的环境中同时操作HashMap，建议使用ConcurrentHashMap。

(4) JDK1.8引入红黑树大程度优化了HashMap的性能。

参考
Java 8系列之重新认识HashMap

• —软件人才免语言低担保 赴美带薪读研！—

栈

一般是指 堆内存(Heap)的管理，因为栈(stack)、PC寄存器(PC Register)、本地方法栈(Native Method Stack)都是和线程一样的生命周期
-Xss 设置栈内存大小
栈是不需要垃圾回收的，尽管说垃圾回收是java内存管理的一个很热的话题，栈中的对象如果用垃圾回收的观点来看，他永远是live状态，是可以reachable的，所以也不需要回收，他占有的空间随着Thread的结束而释放

堆

堆内存分为以下几个区：
Old Space 、 Eden 、From Space、To Space

图示

-Xms和-Xmx来指定堆内存最小值和最大值
通过-Xmn来指定Young Generation的大小
通过-XX:NewRatio来指定Eden区的大小，在Xms和Xmx相等的情况下，该参数不需要设置
通过-XX：SurvivorRatio来设置Eden和一个Survivor区的比值

垃圾回收

JVM中会在以下情况触发回收

1. 对象没有被引用

2. 作用域发生未捕捉异常

3. 程序正常执行完毕

4. 程序执行了System.exit()

5. 程序发生意外终止

如何确定某个对象是垃圾

1.引用计数法：对象配备一个整形计数器，引用一次+1，引用失效-1，计数器=0，表示对象不再被使用
2.可达性分析：GC Roots，如果一个对象不能达到GC Roots的时候，说明可以被回收

垃圾回收算法

1.标记清除法：标记阶段(标记出所有需要被回收的对象)，清除阶段(回收被标记的对象所占用的空间)

标记清除法

注意：标记清除算法先通过根节点标记所有可达对象，然后清除所有不可达对象，完成垃圾回收
缺点：效率低，内存碎片化严重(后续大对象找不到可利用的空间)

2.复制算法：将内存容量分成两块，每次只使用其中一块，当这块内存用完的时候，将存活的对象复制到另外一块，然后再把已使用的内存空间一次性清理掉

 

复制算法

优点：算法实现简单，效率高，不易产生碎片
缺点：内存使用空间被压缩到一半

3.标记整理法：与标记清除法一样，区别在与完成标记后，不是直接清理可回收对象，而是将存活对象都移向内存的一端，然后清理掉端边界以后的内存

 

标记整理法

注意：标记整理算法的最终效果等同于标记清除算法执行完成后，再进行一次内存碎片的整理，因此也叫标记清除压缩算法

4.分代收集法：
核心思想：根据对象的存活生命周期将内存划分为若干不同的区域
新生代：每次垃圾回收时都有大量对象被回收
老年代：每次垃圾回收时只有少量对象需要被回收
新生代一般采用复制算法
老年代采用标记整理算法

注意：在堆之外还有一个永久代(Permanent Generation)，它用来存储class类，方法，常量描述等。对永久代的回收主要包括废弃常量和无用的类

垃圾收集器

新生代垃圾收集器有Serial、ParNew、Parallel Scavenge，G1，属于老年代的垃圾收集器有CMS、Serial Old、Parallel Old和G1.其中的G1是一种既可以对新生代对象也可以对老年代对象进行回收的垃圾收集器。

Serial 单线程垃圾收集器，针对新生代的收集器，采用复制算法

ParNew Serial收集器的多线程版本，采用复制算法，伴随着CPU数量的增加，收集效率也会大大增加

Parallel Scavenge 并行收集器，采用复制算法，关注系统吞吐量

G1收集器(整个Java堆：包括新生代和老年代)

特点

并行与并发

分代收集（仍然保留了分代的概念）

空间整合（整体上属于“标记-整理”算法，不会导致空间碎片）

可预测的停顿（比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒）

Serial Old serial的老年代版本，采用标记整理算法 单线程

Parallel Old Parallel Scavenge的老年代版本，采用标记整理算法 多线程

CMS收集器 以最小回收时间停顿为目标的并发回收器，采用标记清除算法

垃圾收集器一览表

参考:
JVM垃圾回收算法
JVM重要知识点整理和学习
JVM垃圾回收算法和垃圾收集器

• —软件人才免语言低担保 赴美带薪读研！—

什么是分布式锁？

控制分布式架构中多个模块访问的优先级

要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。

线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量（state）。

进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。

分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

分布式锁实现方式

1.基于数据库实现分布式锁

基于数据库表

往数据库中插入数据，插入成功获取访问资源的锁，访问完成，删除数据库中对应的记录，释放访问资源的锁
要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。

当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

创建这样一张数据库表：

 

image

当我们想要锁住某个方法时，执行以下SQL：

 

image

创建表示我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁
当方法执行完毕之后，想要释放锁的话，需要执行以下Sql:

 

image

上面这种实现有以下几个问题：
1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
解决方法：

1. 数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上
2. 没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
3. 非阻塞的？搞一个while循环，直到insert成功再返回成功。
4. 非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

存在的问题：

• 删除记录失败，会导致其他进程无法获取访问资源的锁
• insert记录并不是重入锁

解决方法：

判断当前获取的锁是不是当前节点的
每个节点或者进程加一个id，删除失败获取节点的id是不是等于当前节点的id，是的话，可以继续去做，即可重入锁

基于数据库排他锁

除了可以通过增删操作数据表中的记录以外，其实还可以借助数据中自带的锁来实现分布式的锁。

我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。 基于MySql的InnoDB引擎，可以使用以下方法来实现加锁操作：

 

image

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁（这里再多提一句，InnoDB引擎在加锁的时候，只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。这里我们希望使用行级锁，就要给method_name添加索引，值得注意的是，这个索引一定要创建成唯一索引，否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也加上。）。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

 

image

通过connection.commit()操作来释放锁。
这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。
但是还是无法直接解决数据库单点和可重入问题。

这里还可能存在另外一个问题，虽然我们对method_name 使用了唯一索引，并且显示使用for update来使用行级锁。但是，MySql会对查询进行优化，即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。如果发生这种情况就悲剧了

2. 基于Zookeeper实现分布式锁

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：

（1）创建一个目录mylock；
（2）线程A想获取锁就在mylock目录下创建临时顺序节点；
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。
可以直接使用zookeeper第三方库Curator客户端，这个客户端中封装了一个可重入的锁服务。

 

image

Curator提供的InterProcessMutex是分布式锁的实现。acquire方法用户获取锁，release方法用于释放锁。

使用ZK实现的分布式锁好像完全符合了本文开头我们对一个分布式锁的所有期望。但是，其实并不是，Zookeeper实现的分布式锁其实存在一个缺点，那就是性能上可能并没有缓存服务那么高。因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上。

其实，使用Zookeeper也有可能带来并发问题，只是并不常见而已。考虑这样的情况，由于网络抖动，客户端可ZK集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。就可能产生并发问题。这个问题不常见是因为zk有重试机制，一旦zk集群检测不到客户端的心跳，就会重试，Curator客户端支持多种重试策略。多次重试之后还不行的话才会删除临时节点。（所以，选择一个合适的重试策略也比较重要，要在锁的粒度和并发之间找一个平衡。）

3.基于缓存实现分布式锁

setnx

三种方案的比较

上面几种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。
从理解的难易程度角度（从低到高）
数据库 > 缓存 > Zookeeper
从实现的复杂性角度（从低到高）
Zookeeper >= 缓存 > 数据库
从性能角度（从高到低）
缓存 > Zookeeper >= 数据库
从可靠性角度（从高到低）
Zookeeper > 缓存 > 数据库
参考：

分布式锁的几种实现方式
分布式锁简单入门以及三种实现方式介绍
分布式锁的作用及实现（Redis）

• —软件人才免语言低担保 赴美带薪读研！—

spring集成redis遇到的一些问题

1.Error creating bean with name 'enableRedisKeyspaceNotificationsInitializer' defined in class path resource 好像看不出报的什么错，继续往下看详细信息

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 
'enableRedisKeyspaceNotificationsInitializer' defined in class path resource 
[org/springframework/session/data/redis/config/annotation/web/http/RedisHttpSessionConfiguration.class]: 
Invocation of init method failed; 
nested exception is java.lang.IllegalStateException: Unable to configure Redis to keyspace notifications. 
See http://docs.spring.io/spring-session/docs/current/reference/html5/#api-redisoperationssessionrepository-sessiondestroyedevent

 详细报错信息如下：

23:30:46.489 [RMI TCP Connection(5)-127.0.0.1] ERROR org.springframework.web.servlet.DispatcherServlet - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'enableRedisKeyspaceNotificationsInitializer' defined in class path resource [org/springframework/session/data/redis/config/annotation/web/http/RedisHttpSessionConfiguration.class]: Invocation of init method failed; nested exception is java.lang.IllegalStateException: Unable to configure Redis to keyspace notifications. See http://docs.spring.io/spring-session/docs/current/reference/html5/#api-redisoperationssessionrepository-sessiondestroyedevent
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1710)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:583)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:502)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:312)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:310)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:760)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:868)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:549)
	at org.springframework.web.servlet.FrameworkServlet.configureAndRefreshWebApplicationContext(FrameworkServlet.java:676)
	at org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:642)
	at org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:690)
	at org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:558)
	at org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:499)
	at org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:172)
	at javax.servlet.GenericServlet.init(GenericServlet.java:160)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1280)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1193)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5123)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5407)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
	at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1552)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
	at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:622)
	at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:569)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
	at sun.rmi.transport.Transport$1.run(Transport.java:200)
	at sun.rmi.transport.Transport$1.run(Transport.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Unable to configure Redis to keyspace notifications. See http://docs.spring.io/spring-session/docs/current/reference/html5/#api-redisoperationssessionrepository-sessiondestroyedevent
	at org.springframework.session.data.redis.config.ConfigureNotifyKeyspaceEventsAction.getNotifyOptions(ConfigureNotifyKeyspaceEventsAction.java:83)
	at org.springframework.session.data.redis.config.ConfigureNotifyKeyspaceEventsAction.configure(ConfigureNotifyKeyspaceEventsAction.java:57)
	at org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration$EnableRedisKeyspaceNotificationsInitializer.afterPropertiesSet(RedisHttpSessionConfiguration.java:286)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
	... 64 common frames omitted
Caused by: org.springframework.dao.InvalidDataAccessApiUsageException: DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.; nested exception is redis.clients.jedis.exceptions.JedisDataException: DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
	at org.springframework.data.redis.connection.jedis.JedisExceptionConverter.convert(JedisExceptionConverter.java:64)
	at org.springframework.data.redis.connection.jedis.JedisExceptionConverter.convert(JedisExceptionConverter.java:41)
	at org.springframework.data.redis.PassThroughExceptionTranslationStrategy.translate(PassThroughExceptionTranslationStrategy.java:44)
	at org.springframework.data.redis.FallbackExceptionTranslationStrategy.translate(FallbackExceptionTranslationStrategy.java:42)
	at org.springframework.data.redis.connection.jedis.JedisConnection.convertJedisAccessException(JedisConnection.java:181)
	at org.springframework.data.redis.connection.jedis.JedisServerCommands.convertJedisAccessException(JedisServerCommands.java:531)
	at org.springframework.data.redis.connection.jedis.JedisServerCommands.getConfig(JedisServerCommands.java:299)
	at org.springframework.data.redis.connection.DefaultedRedisConnection.getConfig(DefaultedRedisConnection.java:1119)
	at org.springframework.session.data.redis.config.ConfigureNotifyKeyspaceEventsAction.getNotifyOptions(ConfigureNotifyKeyspaceEventsAction.java:76)
	... 68 common frames omitted
Caused by: redis.clients.jedis.exceptions.JedisDataException: DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
	at redis.clients.jedis.Protocol.processError(Protocol.java:127)
	at redis.clients.jedis.Protocol.process(Protocol.java:161)
	at redis.clients.jedis.Protocol.read(Protocol.java:215)
	at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340)
	at redis.clients.jedis.Connection.getBinaryMultiBulkReply(Connection.java:276)
	at redis.clients.jedis.Connection.getMultiBulkReply(Connection.java:269)
	at redis.clients.jedis.Jedis.configGet(Jedis.java:2630)
	at org.springframework.data.redis.connection.jedis.JedisServerCommands.getConfig(JedisServerCommands.java:297)
	... 70 common frames omitted

 86行，DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients.由于启用了保护模式，没有指定绑定地址，也没有向客户端请求身份验证密码，因此拒绝redis在保护模式下运行。

解决方案：

修改配置文件redis.conf

# accept connections only from clients running into the same computer it
# is running).
#
# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
# JUST COMMENT THE FOLLOWING LINE.
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#bind 127.0.0.1

# Protected mode is a layer of security protection, in order to avoid that
# Redis instances left open on the internet are accessed and exploited.
#
# When protected mode is on and if:
#
# 1) The server is not binding explicitly to a set of addresses using the
#    "bind" directive.
# 2) No password is configured.
#
# The server only accepts connections from clients connecting from the
# IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix domain
# sockets.
#
# By default protected mode is enabled. You should disable it only if
# you are sure you want clients from other hosts to connect to Redis
# even if no authentication is configured, nor a specific set of interfaces
# are explicitly listed using the "bind" directive.
protected-mode no

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379

# TCP listen() backlog.
#
# In high requests-per-second environments you need an high backlog in order
# to avoid slow clients connections issues. Note that the Linux kernel
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog

 如上 注释 bind 127.0.0.1

将 protected-mode yes 改为 protected-mode no

2.redis启动

通过启动参数告诉redis使用指定配置文件使用下面命令启动。

[root@eth-01 redis-3.2.8]# ./src/redis-server redis.conf

 redis.conf是一个默认的配置文件。我们可以根据需要使用自己的配置文件。

redis入门网站：

官方网站：https://redis.io/

中文网站：http://www.redis.net.cn/

http://www.redis.cn/

• —软件人才免语言低担保 赴美带薪读研！—

换了mac电脑，依据windows下idea的设置，依次File-->Othering Settings-->Default Settings ->Inspections->Serialization issues，将serialzable class without "serialVersionUID"打上勾，Apply之后，选中类名，按atl＋enter键，依旧不会提示生成serialVersionUID；

其实mac下提示生成serialVersionUID的方式如下(亲测可用)：

Mac版本是设置Preferences，具体步骤如下：

IntelliJ IDEA-->Preferences-->Inspections-->Java-->Serialization issues,将serialzable class without "serialVersionUID"打上勾

如若有误，欢迎留言指正

• —软件人才免语言低担保 赴美带薪读研！—