面经地址：https://www.nowcoder.com/discuss/457325
第一轮面试：
问题1： Java map
将键映射到值的对象
一个映射不能包含重复的键
每个键最多只能映射到一个值
Map接口和Collection接口的不同
Map是双列的,Collection是单列的
Map的键唯一,Collection的子体系Set是唯一的
Map集合的数据结构针对键有效，跟值无关;Collection集合的数据结构是针对元素有效
包括HashMap集合、LinkedHashMap集合。
HashMap<K,V>：存储数据采用的哈希表结构，元素的存取顺序不能保证一致。
LinkedHashMap<K,V>：HashMap下有个子类LinkedHashMap，存储数据采用的哈希表结构+链表结构。通过链表结构可以保证元素的存取顺序一致；通过哈希表结构可以保证的键的唯一、不重复，需要重写键的hashCode()方法、equals()方法。
常用方法：
get方法：获取指定键(key)所对应的值(value)
put方法：将指定的键与值对应起来，并添加到集合中
remove方法：根据指定的键(key)删除元素，返回被删除元素的值(value)。
问题2：线程的同步机制
一、互斥锁(mutex)
通过锁机制实现线程间的同步。同一时刻只允许一个线程执行一个关键部分的代码。
① 互斥量被初始化为非锁定状态
② 线程1调用pthread_mutex_lock函数，立即返回，互斥量呈锁定状态；
③ 线程2调用pthread_mutex_lock函数，阻塞等待；
④ 线程1调用pthread_mutex_unlock函数，互斥量呈非锁定状态;
⑤ 线程2被唤醒，从pthread_mutex_lock函数中返回，互斥量呈锁定状态
互斥锁是用在多线程多任务互斥的，一个线程占用了某一个资源，那么别的线程就无法访问，直到这个线程unlock，其他的线程才开始可以利用这 个资源。
二、信号量(sem)
如同进程一样，线程也可以通过信号量来实现通信，虽然是轻量级的。信号量是一个计数器，用于控制访问有限共享资源的线程数。
特点：信号量用在多线程多任务同步的，一个线程完成了某一个动作就通过信号量告诉别的线程，别的线程再进行某些动作
三、条件变量（cond）
条件变量可以让调用线程在满足特定条件的情况下暂停。
问题三：线程安全
线程的工作内存是线程私有内存，线程间无法互相访问对方的工作内存。JMM 规定了何时以及如何做线程工作内存与主内存之间的数据同步。
主内存中的变量是共享的，所有线程都可以访问读写，而线程工作内存又是线程私有的，线程间不可互相访问。那在多线程场景下，图上的线程 A 和线程 B 同时来操做共享内存里的同一个变量，那么主内存内的此变量数据就会被破坏。也就是说主内存内的此变量不是线程安全的。Java 提供了一系列的关键字和类来保证线程安全。
一，Synchronized 关键字
Synchronized 保证⽅法内部或代码块内部资源（数据）的互斥访问。即同⼀时间、由同⼀个 Monitor（监视锁） 监视的代码，最多只能有⼀个线程在访问。
- 保证方法或代码块操作的原子性
被 Synchronized 关键字描述的方法或代码块在多线程环境下同一时间只能由一个线程进行访问，在持有当前 Monitor 的线程执行完成之前，其他线程想要调用相关方法就必须进行排队，知道持有持有当前 Monitor 的线程执行结束，释放 Monitor ，下一个线程才可获取 Monitor 执行。如果存在多个 Monitor 的情况时，多个 Monitor 之间是不互斥的。
2.保证监视资源的可见性
保证多线程环境下对监视资源的数据同步。即任何线程在获取到 Monitor 后的第⼀时 间，会先将共享内存中的数据复制到⾃⼰的缓存中；任何线程在释放 Monitor 的第⼀ 时间，会先将缓存中的数据复制到共享内存中。
3.保证线程间操作的有序性
Synchronized 的原子性保证了由其描述的方法或代码操作具有有序性，同一时间只能由最多只能有一个线程访问，不会触发 JMM 指令重排机制。
二，Volatile 关键字
保证被 Volatile 关键字描述变量的操作具有可见性和有序性（禁止指令重排）
三， java.util.concurrent.atomic
java.util.concurrent.atomic 包提供了一系列的 AtomicBoolean、AtomicInteger、AtomicLong 等类。使用这些类来声明变量可以保证对其操作具有原子性来保证线程安全。实现原理上与 Synchronized 使用 Monitor（监视锁）保证资源在多线程环境下阻塞互斥访问不同，java.util.concurrent.atomic 包下的各原子类基于 CAS(CompareAndSwap) 操作原理实现。
总结：
出现线程安全问题的原因：
在多个线程并发环境下，多个线程共同访问同一共享内存资源时，其中一个线程对资源进行写操作的中途(写⼊入已经开始，但还没 结束)，其他线程对这个写了一半的资源进⾏了读操作，或者对这个写了一半的资源进⾏了写操作，导致此资源出现数据错误。
如何避免线程安全问题？
保证共享资源在同一时间只能由一个线程进行操作(原子性，有序性)。将线程操作的结果及时刷新，保证其他线程可以立即获取到修改后的最新数据（可见性）。
问题四：osi七层模型
问题五：三次握手，四次挥手
三次握手：
第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
四次挥手：
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其***为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的***seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的***为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的***是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
问题六：TCP和UDP的区别
1、基于连接与无连接； 2、对系统资源的要求（TCP较多，UDP少）；3、UDP程序结构较简单；4、流模式与数据报模式 ；5、TCP保证数据正确性，UDP可能丢包；6、TCP保证数据顺序，UDP不保证。