java常见问题(不断更新,附源码解析)
文章目录
- open-jdk
- ThreadLocal
- 为何存在内存泄漏问题?
- ArrayList
- 并发修改抛出异常?
- HashMap
- 什么时候采用红黑树?
- 为什么每次扩容后,是2的幂次方?
- 为什么扩容后,相同的在原位置保存,而不同的则当前索引+之前原位置索引保存?
- 为啥用尾插法?
- 为什么线程不安全?
- hashcode如何计算? TODO
- 为什么红黑树?平衡二叉树不行么？TODO
- ConcurrentHashMap
- 什么时候扩容?
- JDK1.8放弃分段锁
- jdk1.8的map实现
- 为什么不用ReentrantLock而用synchronized ?
- 多个线程又是如何同步处理的呢？
- ThreadPoolExecutor
- 执行过程
- Thread todo
- 守护线程
- 运行到一半的线程能否被强制杀死？
- 线程间通信机制有哪些？
- 关闭线程的合理的方法是什么？
- 线程状态切换
- JVM
- 为啥8:1:1
- 收集器区别
- 如何选择垃圾回收器
- 对象回收流程 todo
- 垃圾回收算法
- 内存模型 todo
- 内存分配执行过程
- volatile
- synchronized
- synchronized和cas适用场景?
- 框架
- spring
- spring如何实现标签功能扩展的?
- spring如何解决循环依赖?
- BeanFactoryPostProcessors和BeanPostProcessors区别
- spring加载xml过程
- spring获取对象过程
- spring-aop执行过程(重点)
- cglib和动态代理区别
- spring选择
- mybatis如何和spring整合? todo
- 通讯协议
- tcp为什么不二次握手就建立连接?
- 已经建立连接,客户端突然崩了?TCP怎么处理?
- 为什么连接的时候是三次握手，关闭的时候却是四次挥手？
- 为什么四次挥手后客户端还需要等待2MSL(最大报文段生存时间)才进行最终关闭？
- 为什么不三次挥手?
- 流量控制? todo
- 拥塞控制？todo
- 其他
- 同步和阻塞关系?
- 闭锁,计数信号量,栅栏使用场景?
- 栅栏与闭锁区别？
- 信号量和同步锁的区别
面试过程中遇到了很多问题,之前看了源码,但并未带着问题去看.现在开始带着问题去看源码.里面有一些问题是自己提问的.另外涉及到源码的都附了源码解析链接(不错,是我写的).
KO!!! 感觉就像使用费曼学习法一样,每次面试都能提高自己.
open-jdk
ThreadLocal
添加链接描述
为何存在内存泄漏问题?
内存泄漏的根本原因是强引用和弱引用的生命周期不一致造成的.ThreadLocal作为一个虚引用的key,当被GC回收时,但是value,被当前线程的ThreadLocalMap持有,只要当前线程不销毁,或者没调用get/set方法(调用get/set时,会清除null为key的数据),就一直持有
最严重的的情况是使用了线程池或者静态声明ThreadLocal,大大延长了二者的生命周期.没能及时回收null数据,所以内存泄漏咯
ArrayList
并发修改抛出异常?
当采用迭代器遍历的时候,利用mod和迭代器的expectedModCount记录修改次数,根据迭代器和ArrayList的修改次数判断是否并发修改,从而快速失败
HashMap
添加链接描述
什么时候采用红黑树?
当桶里面存的链表个数>8,同时数组长度>64,的时候采用红黑树
默认加载因子0.75
默认容量16,加载扩容的大小12
key一样时,覆盖旧的value
可以存null,索引0
为什么每次扩容后,是2的幂次方?
是因为在使用2的幂的数字的时候，Length-1的值是所有二进制位全为1，这种情况下，index的结果等同于HashCode后几位的值。
只要输入的HashCode本身分布均匀，Hash算法的结果就是均匀的。
这是为了实现均匀分布。
为什么扩容后,相同的在原位置保存,而不同的则当前索引+之前原位置索引保存?
//因为这里的扩容都是扩容一倍,也就是01000扩容后变成10000
// 当e.hash & oldCap == 0,说明hash<当前容量,也就是落在0~1000范围内,哪怕扩容后,进行&操作也是一样的索引值
//!=0,则说明第一e.hash落在0~1000范围内,第二包含1000这个位置.而1000是之前扩容前的容量,所以最新的地址为扩容前容量+当前索引
//原位置保存
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
//存储索引在扩容的那部分
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
为啥用尾插法?
jdk7因为头插法存在环形问题
而jdk8,使用尾插，在扩容时会保持链表元素原本的顺序，就不会出现链表成环的问题了
为什么线程不安全?
在jdk1.7中，在多线程环境下，扩容时会造成环形链或数据丢失。
在jdk1.8中，在多线程环境下，会发生数据覆盖的情况。
hashcode如何计算? TODO
为什么红黑树?平衡二叉树不行么？TODO
ConcurrentHashMap
添加链接描述
什么时候扩容?
- 单节点容量>=8且容量<64,则扩容一倍
- 当数组中元素达到了sizeCtl的数量的时候，则会调用transfer方法来进行扩容
没有实现对map进行加锁来执行独占访问,因为采用了分段锁,所以无法使用客户端加锁来创建新的原子操作,如若没有则添加之内操作.
JDK1.8放弃分段锁
段Segment继承了重入锁ReentrantLock，有了锁的功能，每个锁控制的是一段，当每个Segment越来越大时，锁的粒度就变得有些大了。
分段锁的优势在于保证在操作不同段 map 的时候可以并发执行，操作同段 map 的时候，进行锁的竞争和等待。这相对于直接对整个map同步synchronized是有优势的。
缺点在于分成很多段时会比较浪费内存空间(不连续，碎片化); 操作map时竞争同一个分段锁的概率非常小时，分段锁反而会造成更新等操作的长时间等待; 当某个段很大时，分段锁的性能会下降。
jdk1.8的map实现
和hashmap一样,jdk 1.8中ConcurrentHashmap采用的底层数据结构为数组+链表+红黑树的形式。数组可以扩容，链表可以转化为红黑树。
为什么不用ReentrantLock而用synchronized ?
减少内存开销:如果使用ReentrantLock则需要节点继承AQS来获得同步支持，增加内存开销，而1.8中只有头节点需要进行同步。
内部优化:synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。
多个线程又是如何同步处理的呢？
- 同步处理主要是通过Synchronized和unsafe两种方式来完成的。
- 在取得sizeCtl、某个位置的Node的时候，使用的都是unsafe的方法，来达到并发安全的目的
当需要在某个位置设置节点的时候，则会通过Synchronized的同步机制来锁定该位置的节点。 - 在数组扩容的时候，则通过处理的步长和fwd节点来达到并发安全的目的，通过设置hash值为MOVED
- 当把某个位置的节点复制到扩张后的table的时候，也通过Synchronized的同步机制来保证现程安全
ThreadPoolExecutor
添加链接描述
执行过程
- 当前工作线程个数<核心大小添加新线程工作
- 核心池都在运行状态，添加到队列中
- 核心池没处于运行状态或者队列已满，试着创建线程最大线程数新开一个新线程处理
- 如果创建新线程失败了，说明线程池被关闭或者线程池完全满了，拒绝任务
Thread todo
守护线程
坦克大战里面的坦克(守护线程).家(用户线程)都被炸了,坦克也得凉凉.
线程礼让,yield
运行到一半的线程能否被强制杀死？
答案是不能，虽然我们可以用stop(),destroy()这些函数强制杀死他，但是这些函数，官方不建议使用，强势杀死线程会导致线程中所用的资源，例如文件描述符，网络连接等不能正常关闭。
线程间通信机制有哪些？
共享内存，在java中使用这种机制进行线程通信，所以在使用起来会应用到锁机制，或者CAS自旋机制
消息传递
关闭线程的合理的方法是什么？
等待线程执行完毕
如果是不断循环运行的线程，需要利用线程间通信机制，通知线程退出
线程状态切换
JVM
为啥8:1:1
GC是统计学测算出当内存使用超过98%以上时，内存就应该被minor gc时回收一次。但是实际应用中，我们不能较真的只给 他们留下2%，换句话说当内存使用达到98%时才GC 就有点晚了，应该是多一些预留10%内存空间，这预留下来的空间我们称为S区（有两个s区 s1 和 s0），S区是用来存储新生代GC后存活下来的对象，而我们知道新生代GC算法使用的是复制回收算法。
所以我们实际GC发生是在，新生代内存使用达到90%时开始进行，复制存活的对象到S1区，要知道GC结束后在S1区活下来的对象，需要放回给S0区，也就是对调(对调是指，两个S区位置互换,意味着再一次minor gc 时的区域 是eden 加，上一次存活的对象放入的S区)，既然能对调，其实就是两个区域一般大。这也是为什么会再有个10%的S0区域出来。这样比例就是8:1:1了!!（80%：s1:s0=80%:10%:10%=8:1:1）这里的eden区（80%） 和其中的一个 S区（10%） 合起来共占据90%，GC就是清理的他们，始终保持着其中一个 S 区是空留的，保证GC的时候复制存活的对象有个存储的地方。
收集器区别
串行收集器:单线程执行,适合单核CPU
并行收集器:吞吐量回收器,并行执行年轻代垃圾回收,多条垃圾收集器并行工作,此时用户线程依然处于等待状态.适用于多核处理器或多线程硬件上运行数据量较大应用
并发收集器:并发回收,缩短垃圾回收暂停时间,适用响应时间>吞吐时间应用,用户线程与垃圾收集线程同时执行,但不一定并行,可能交替,但会降低应用程序性能
CMS收集器:并发标记清除收集器,适用于缩短垃圾回收暂停时间并且负担得起与垃圾回收共享处理器资源的应用
G1收集器:适用于大容量内存的多核服务器,可以满足垃圾回收暂停时间目标的同时,以最大可能性实现高吞吐,(JDK1.7)
如何选择垃圾回收器
数据量小,或者运行单核且没有暂停时间要求,串行收集器
考虑系统峰值性能,没有暂停时间要求,并行
响应时间>吞吐,并发
对象回收流程 todo
垃圾回收算法
标记清除
标记复制
标记整理
分代收集算法
引用计数算法
判断对象是否存活常用算法
引用计数算法：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值+1，当引用失效时，计数器值-1.
任何时刻计数器都为0的对象就是不可能在被使用。
效率高，但很难解决对象之间的相互循环引用的问题
根搜索算法
通过一系列名为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链
当一个对象到GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达)时，
则证明此对象是不可用的，
java语言中，作为GC Roots的对象包括下面几种
1:虚拟机栈(栈帧中的本地变量表)中的引用的对象
2：方法去中的类静态属性引用的对象
3：方法区中的常量引用的对象
4：本地方法栈中jni(即一般说的native方法)的引用的对象
5所有被同步锁（synchronized关键字）持有的对象。
6:·反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
内存模型 todo
内存分配执行过程
XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC
-Xms20M -Xmx20M:限制堆大小20M
-Xmn10M ：分配给新生代,剩余的10M分配给老年代
-XX:SurvivorRatio=8：决定了新生代中的Eden区与Survivor区的空间比例时8：1
-XX:+UseSerialGC:使用Serial+Serial Old的收集器组合进行内存回收
存储对象时,先存储到Eden+Survivor中,也就是容量9/10*10M,存储容量超过Eden+Survivor,进行一次Minor GC,
将对象存储另外一个Survivor中,如果存储成功对象年龄设为1,对象在Survivor区中每熬过一次Minor GC，年龄增加一岁,当他的年龄达到一定程度(默认15)，晋升到老年代。
无法完全放入Survivor区，就会向老年代借用内存存放对象，以完成Minor GC,在触发Minor GC时，虚拟机会先检测之前晋升到老年代内存的平均大小是否大于老年代的剩余内存，如果大于，则将Minor GC变为一次Full GC，如果小于，则查看虚拟机是否允许担保失败
如果允许担保失败则Minor GC,否则Full GC
volatile
实现原理
synchronized
实现原理
锁优化
synchronized和cas适用场景?
资源竞争频繁用sync,否则cas.
因为sync进行线程阻塞和唤醒以及内核的切换操作会额外消耗CPU
而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，可以获得更好的性能
对于资源竞争严重的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源
synchronized在jdk1.6之后，依靠 Lock-Free，基本思路是自旋后阻塞，在线程冲突较少的情况下，可以获得和CAS类似的性能，而线程冲突严重的情况下，性能远高于CAS
框架
spring
spring如何实现标签功能扩展的?
spring在解析doc的时候,会创建一个ReaderContext对象
ReaderContext对象创建的时候,会创建NamespaceHandlerResolver对象
在进行对象解析的时候,会分别解析默认命名空间和自定义的解析,也就是beans标签和非beans标签的解析
/*
获取所有已经配置的handler映射,读取配置文件
根据命名空间找到对应的信息
当是类的时候说明,已经做过解析直接缓存读取,直接返回
没有做过解析,返回类路径
判断handlerClass是否是NamespaceHandler子类
初始化类
调用自定义的namespaceHandler的初始化方法,这个时候注入了解析器
记录在缓存
返回
*/
public NamespaceHandler resolve(String namespaceUri) {
//获取所有已经配置的handler映射,读取配置文件
//和类org.springframework.beans.factory.xml.PluggableSchemaResolver.getSchemaMappings一样,不在阐述
Map<String, Object> handlerMappings = getHandlerMappings();
//根据命名空间找到对应的信息
Object handlerOrClassName = handlerMappings.get(namespaceUri);
if (handlerOrClassName == null) {
return null;
}
//这个时候还是字符串
else if (handlerOrClassName instanceof NamespaceHandler) {
//已经做过解析,直接缓存读取
return (NamespaceHandler) handlerOrClassName;
}
else {
//没有做过解析,返回类路径
String className = (String) handlerOrClassName;
try {
Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);
//判断handlerClass是否是NamespaceHandler子类
if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) {
throw new FatalBeanException("Class [" + className + "] for namespace [" + namespaceUri +
"] does not implement the [" + NamespaceHandler.class.getName() + "] interface");
}
//初始化类
NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);
//调用自定义的namespaceHandler的初始化方法,这个时候注入了解析器
namespaceHandler.init();
//记录在缓存
handlerMappings.put(namespaceUri, namespaceHandler);
return namespaceHandler;
}
catch (ClassNotFoundException ex) {
throw new FatalBeanException("Could not find NamespaceHandler class [" + className +
"] for namespace [" + namespaceUri + "]", ex);
}
catch (LinkageError err) {
throw new FatalBeanException("Unresolvable class definition for NamespaceHandler class [" +
className + "] for namespace [" + namespaceUri + "]", err);
}
}
}
注册命名空间能解析的elementName
public class AopNamespaceHandler extends NamespaceHandlerSupport {
/**
* Register the {@link BeanDefinitionParser BeanDefinitionParsers} for the
* '{@code config}', '{@code spring-configured}', '{@code aspectj-autoproxy}'
* and '{@code scoped-proxy}' tags.
*/
@Override
public void init() {
// In 2.0 XSD as well as in 2.1 XSD.
registerBeanDefinitionParser("config", new ConfigBeanDefinitionParser());
registerBeanDefinitionParser("aspectj-autoproxy", new AspectJAutoProxyBeanDefinitionParser());
registerBeanDefinitionDecorator("scoped-proxy", new ScopedProxyBeanDefinitionDecorator());
// Only in 2.0 XSD: moved to context namespace as of 2.1
registerBeanDefinitionParser("spring-configured", new SpringConfiguredBeanDefinitionParser());
}
}
接着会读取META-INF/spring.handlers文件配置的命名空间解析器
private Map<String, Object> getHandlerMappings() {
Map<String, Object> handlerMappings = this.handlerMappings;
if (handlerMappings == null) {
synchronized (this) {
handlerMappings = this.handlerMappings;
if (handlerMappings == null) {
if (logger.isTraceEnabled()) {
logger.trace("Loading NamespaceHandler mappings from [" + this.handlerMappingsLocation + "]");
}
try {
Properties mappings =
PropertiesLoaderUtils.loadAllProperties(this.handlerMappingsLocation, this.classLoader);
if (logger.isTraceEnabled()) {
logger.trace("Loaded NamespaceHandler mappings: " + mappings);
}
handlerMappings = new ConcurrentHashMap<>(mappings.size());
CollectionUtils.mergePropertiesIntoMap(mappings, handlerMappings);
this.handlerMappings = handlerMappings;
}
catch (IOException ex) {
throw new IllegalStateException(
"Unable to load NamespaceHandler mappings from location [" + this.handlerMappingsLocation + "]", ex);
}
}
}
}
return handlerMappings;
}
然后根据url获取对应的解析器,然后解析
public BeanDefinition parse(Element element, ParserContext parserContext) {
//寻找解析器并进行解析操作
BeanDefinitionParser parser = findParserForElement(element, parserContext);
//AbstractBeanDefinitionParser.parse
return (parser != null ? parser.parse(element, parserContext) : null);
}
/*
调用自定义的解析器类
对id的支持
对name别名注册的支持
将AbstractBeanDefinition转换为BeanDefinitionHolder并注册
注册别名
子类后续处理
通知监听器,注册完成
*/
public final BeanDefinition parse(Element element, ParserContext parserContext) {
//内部调用了自定义的解析器类
AbstractBeanDefinition definition = parseInternal(element, parserContext);
if (definition != null && !parserContext.isNested()) {
try {
//对id的支持,当没id的时候,使用内部构造名字
String id = resolveId(element, definition, parserContext);
if (!StringUtils.hasText(id)) {
parserContext.getReaderContext().error(
"Id is required for element '" + parserContext.getDelegate().getLocalName(element)
+ "' when used as a top-level tag", element);
}
//对name别名注册的支持
String[] aliases = null;
if (shouldParseNameAsAliases()) {
String name = element.getAttribute(NAME_ATTRIBUTE);
if (StringUtils.hasLength(name)) {
aliases = StringUtils.trimArrayElements(StringUtils.commaDelimitedListToStringArray(name));
}
}
//将AbstractBeanDefinition转换为BeanDefinitionHolder并注册
BeanDefinitionHolder holder = new BeanDefinitionHolder(definition, id, aliases);
//注册别名以及名字,还有BeanDefinition
registerBeanDefinition(holder, parserContext.getRegistry());
if (shouldFireEvents()) {
//需要通知监听器则进行处理
BeanComponentDefinition componentDefinition = new BeanComponentDefinition(holder);
//子类后续处理
postProcessComponentDefinition(componentDefinition);
//通知监听器,注册完成
parserContext.registerComponent(componentDefinition);
}
}
catch (BeanDefinitionStoreException ex) {
String msg = ex.getMessage();
parserContext.getReaderContext().error((msg != null ? msg : ex.toString()), element);
return null;
}
}
return definition;
}
/*
获取自定义标签解析器中的class
若没有获取class,则获取beanClassName
继承父类scope
配置延迟加载
调用自定义的解析方法
*/
protected final AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) {
//内部构造了GenericBeanDefinition
BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition();
String parentName = getParentName(element);
if (parentName != null) {
builder.getRawBeanDefinition().setParentName(parentName);
}
//获取自定义标签解析器中的class,此时会调用UserBeanDefinitionParser.getBeanClass
/*
org.example.custom.dtd.UserBeanDefinitionParser.getBeanClass
*/
//调用自定义类获取class对象
Class<?> beanClass = getBeanClass(element);
if (beanClass != null) {
builder.getRawBeanDefinition().setBeanClass(beanClass);
} else {
//若子类没有重写,则尝试子类是否重写了getBeanClassName方法
String beanClassName = getBeanClassName(element);
if (beanClassName != null) {
builder.getRawBeanDefinition().setBeanClassName(beanClassName);
}
}
builder.getRawBeanDefinition().setSource(parserContext.extractSource(element));
BeanDefinition containingBd = parserContext.getContainingBeanDefinition();
//继承父类scope
if (containingBd != null) {
// Inner bean definition must receive same scope as containing bean.
builder.setScope(containingBd.getScope());
}
//配置延迟加载
if (parserContext.isDefaultLazyInit()) {
// Default-lazy-init applies to custom bean definitions as well.
builder.setLazyInit(true);
}
//调用子类重写的方法解析,这里调用了自定义的解析方法
doParse(element, parserContext, builder);
//内部做了loopup-method,replace-method,factory-method覆盖方法的校验
return builder.getBeanDefinition();
}
spring如何解决循环依赖?
创建bean的时候,通过提早暴露一个工厂对象
这样后续填充属性的时候,如果遇到循环依赖会从工厂中获取对象,而因为工厂对象的初始地址是一样的,也就解决了循环依赖问题
BeanFactoryPostProcessors和BeanPostProcessors区别
BeanPostProcessors并不需要马上调用,所以不需要考虑硬编码方式
BeanPostProcessor可以修改实际的bean实例
而BeanFactoryPostProcessors之所以考虑硬编码是因为不仅要实现注册功能，还要实现对后处理器的激活操作，所以需要载入配置中的定义,并进行激活
BeanFactoryPostProcessor作用域容器级,仅仅对容器中的bean进行后置处理,如propertyPlaceholderConfig,继承order可实现排序调用功能
spring加载xml过程
spring加载xml时,2个步骤
第一步
首先验证xml是否正确,会从网络或者本地获取xsd配置文件,也就是META-INF/spring.schemas
第二步解析document获取Definitions
解析默认命名空间和自定义命名空间
自定义的命名空间,会从META-INF/spring.handlers获取命名空间解析器进行解析,这里也是对aop等标签的支持.
spring获取对象过程
这里只有一个重要点就是循环依赖的问题,上述已有解答
spring-aop执行过程(重点)
在xml配置文件中扫描到aop标签的时候,会执行命名空间解析器,对应的根据aop标签注入AnnotationAwareAspectJAutoProxyCreator类,
这个类继承BeanPostProcessor,也就是说会在每次加载bean的时候会执行后置方法postProcessAfterInitialization
进行切点表达式匹配并进行相应增强.
增强的过程中会选择动态代理还是cglib
然后接着就是执行动态代理增强器链或者cglib增强器链
cglib和动态代理区别
动态代理
必须某接口实现,运行期间创建一个接口的实现类
cglib
运行期间生成的代理对象是针对目标类的扩展的子类,底层依赖ASM操作字节码实现,性能比jdk强,不能对声明为final的方法进行代理
spring选择
实现接口,本身是接口,Proxy子类,则默认动态代理
否则cglib,可强制设置使用cglib
mybatis如何和spring整合? todo
通讯协议
tcp/ip
tcp为什么不二次握手就建立连接?
假设C发送给S连接请求分组,S确认应答分组.在确认过程中,如果丢失分组.C将持续等待应答,如果S确认2次握手成功,将直接发送数据分组.而C因为处于等待应答状态,将丢弃数据分组.S在发出分组超时后,将重试.进而产生死锁问题.
已经建立连接,客户端突然崩了?TCP怎么处理?
TCP设有保活计数器,服务端每次接收客户端报文,将重置计数器,通常2小时.当2小时没收到报文,则会发送一个试探报文,间隔75S发送一次,若10次没响应,则关闭连接
为什么连接的时候是三次握手，关闭的时候却是四次挥手？
当服务端接收到FIN,并不会立即关闭socket,因为可能还有其他请求没有处理完,所以只是ACK,我收到消息了.当服务端所有报文发送完毕,才会发送FIN.
为什么四次挥手后客户端还需要等待2MSL(最大报文段生存时间)才进行最终关闭？
假设最后ack服务端后,丢失了.服务端将不停重试发送FIN.所以客户端不能立即关闭,也就是说至少需要等到服务端关闭后,才能关闭.从而设置了一个缓冲时间.在2MSL范围内,等待服务端发送FIN,如果没收到,则假设服务端已经正常关闭,从而关闭.如果收到了FIN,则再次等待2MSL.
为什么不三次挥手?
因为服务端在接收到FIN, 往往不会立即返回FIN, 必须等到服务端所有的报文都发送完毕了，才能发FIN。因此先发一个ACK表示已经收到客户端的FIN，延迟一段时间才发FIN。这就造成了四次挥手。
如果是三次挥手会有什么问题？
等于说服务端将ACK和FIN的发送合并为一次挥手，这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端，从而让客户端不断的重发FIN。
流量控制? todo
拥塞控制？todo
其他
同步和阻塞关系?
同步和异步关注的是消息通信机制,关注的是结果
阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.关注的是过程
同步阻塞
我在手工制作热狗,在制作期间,我不能做其他事
我买了一台制作热狗的机器
同步非阻塞
我用热狗机器制作,在制作期间,我一边玩手机,一边不停地查看热狗机搞好热狗了没有 poll/select
异步阻塞
我去买热狗,老板说还在制作,我走了,临走前我让老板热狗造好后通知我(事件回调).
异步非阻塞
我去买热狗,老板用热狗机器制作,在等他制作期间,我走了,临走前我让老板热狗造好后通知我.而老板在接待下个顾客. epoll
参考地址
闭锁,计数信号量,栅栏使用场景?
Semaphore(计数器):网关限流
CountDownLatch(闭锁):工作中,将db数据全量到搜索引擎时,采用闭锁达到所有数据同步完成后,检测数据同步成功率.如果成功率低,则再次重试.
栅栏:召唤七龙珠.
栅栏与闭锁区别？
栅栏:所有运动员就绪,才能跑步,在所有运动员到达之前,其他就绪运动员(工作线程)都得等.
闭锁:所有运动员到达终点,才开始颁奖.每个运动员到达后,不需要等待其他运动员,只有手持运动员名单的人(主线程),才需要等待.
信号量和同步锁的区别
锁用来一个资源的线程互斥
信号量用来多个同类资源的多个线程互斥与同步
信号量=1 = 锁