1.如何让UDP协议变得可靠？

 UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。

UDP 为什么要可靠？

为什么不是直接用tcp 可靠的协议呢？TCP 是个基于公平性的可靠通信协议，但是在一些苛刻的网络条件下 TCP 要么不能提供正常的通信质量保证，要么成本过高。为什么要在 UDP 之上做可靠保证，究其原因就是在保证通信的时延和质量的条件下尽量降低成本，

所以就有了一种 RUDP改进，它能够解决：

端对端连通性问题：一般终端直接和终端通信都会涉及到 NAT 穿越，TCP 在 NAT 穿越实现非常困难，相对来说 UDP 穿越 NAT 却简单很多，如果是端到端的可靠通信一般用 RUDP 方式来解决，场景有：端到端的文件传输、音视频传输、交互指令传输等等。

弱网环境传输问题：在一些 Wi-Fi 或者 3G/4G 移动网下，需要做低延迟可靠通信，如果用 TCP 通信延迟可能会非常大，这会影响用户体验。例如：实时的操作类网游通信、语音对话、多方白板书写等，这些场景可以采用特殊的 RUDP 方式来解决这类问题。

带宽竞争问题：有时候客户端数据上传需要突破本身 TCP 公平性的限制来达到高速低延时和稳定，也就是说要用特殊的流控算法来压榨客户端上传带宽，例如：直播音视频推流，这类场景用 RUDP 来实现不仅能压榨带宽，也能更好地增加通信的稳定性，避免类似 TCP 的频繁断开重连。

传输路径优化问题：在一些对延时要求很高的场景下，会用应用层 relay 的方式来做传输路由优化，也就是动态智能选路，这时双方采用 RUDP 方式来传输，中间的延迟进行 relay 选路优化延时。还有一类基于传输吞吐量的场景，例如：服务与服务之间数据分发、数据备份等，这类场景一般会采用多点并联 relay 来提高传输的速度，也是要建立在 RUDP 上的（这两点在后面着重来描述）。

资源优化问题：某些场景为了避免 TCP 的三次握手和四次挥手的过程，会采用 RUDP 来优化资源的占用率和响应时间，提高系统的并发能力，例如 QUIC。

那么在 UDP 之上怎么实现可靠呢？答案就是重传。

  包括 定时重传，请求重传，选择重传

RUDP 是通过重传来保证可靠的，重传会引来两个问题，一个是延时，一个是重传的带宽，所以在发送端会设计一个窗口拥塞机制了避免并发带宽占用过高的问题。经典拥塞算法分为四个部分：慢启动、拥塞避免、拥塞处理和快速恢复

2.Java中有哪些集合类

得分点：Set、Quque、List、Map

 Java中的集合类分为4大类，分别由4个接口来代表，它们是Set、List、Queue、Map。                         其中  Set、List、Queue都继承自Collection接口。

· Set代表无序的、元素不可重复的集合。

· List代表有序的、元素可以重复的集合。

· Queue代表先进先出（FIFO）的队列。

· Map代表具有映射关系（key-value）的集合。

 Java提供了众多集合的实现类，它们都是这些接口的直接或间接的实现类，其中比较常用的有：HashSet、TreeSet、ArrayList、LinkedList、ArrayDeque、HashMap、TreeMap等。

加分回答

 上面所说的集合类的接口或实现，都位于java.util包下，这些实现大多数都是非线程安全的。虽然非线程安全，但是这些类的性能较好。如果需要使用线程安全的集合类，则可以利用Collections工具类，该工具类提供的  synchronizedXxx() 方法，可以将这些集合类包装成线程安全的集合类。

 以Concurrent开头的集合类，在多线程读取数据时则没有加锁，以提高读取的性能。在多线程写入数据时加锁，来保证所有写入操作是线程安全的。这些类都采取了比较复杂的算法，在加锁时不会锁住整个集合，从而保证并发写入时具有更好的性能。

 以CopyOnWrite开头的集合类，采用写时复制技术来实现并发写操作，它复制的是底层的数组。当线程读取集合中的数据时，它直接读取集合本身的数据，不会加锁。当线程向集合写入数据时，该集合会在底层复制一份新的数组，然后对这个新数组执行写入操作。由于所有写入操作都是对数组的副本的操作，所以它是线程安全的。

 3.双亲委派机制

jvm 对class 文件采用的是 按需加载的方式，需要时才会加载，采用双亲委派模型进行加载 

 双亲委派模型依赖于三层类加载器：

1. 启动类加载器：这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的类库加载到虚拟机的内存中。

2. 扩展类加载器：这个类加载器负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。

3. 应用程序类加载器：这个类加载器负责加载用户类路径（classpath）上所有的类库。

  双亲委派模型的工作过程是，如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一层都是如此。因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去完成加载。

 双亲委派模型的好处是，Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。  避免了类的重复加载，保护程序安全，防止核心的api 被改动

4. Spring IOC

  IoC是控制反转的意思，是一种面向对象编程的设计思想，spring两大核心之一。在不采用这种思想的情况下，我们需要自己维护对象与对象之间的依赖关系，很容易造成对象之间的耦合度过高。尤其是在一个大型的项目中，对象与对象之间的关系是十分复杂的，这十分不利于代码的维护。IoC则可以解决这种问题，它可以帮我们维护对象与对象之间的依赖关系，并且降低对象之间的耦合度。spring为我们提供了一个ioc容器，也就是beanFactory，同时，ioc有个非常强大的功能，叫做di，也就是依赖注入，我们可以通过配置或者xml文件的方式将bean所依赖的对象通过name（名字）或者type（类别）注入进这个beanFactory中，正因为这个依赖注入，实现类与依赖类之间的解耦，如果在一个复杂的系统中，类之间的依赖关系特别复杂，首先，这非常不利于后期代码的维护，ioc就很好的帮助我们解决了这个问题，它帮助我们维护了类与类之间的依赖关系，降低了耦合性，使我们的类不需要强依赖于某个类，而且，在spring容器启动的时候，spring容器会帮助我们自动的创建好所有的bean，这样，我们程序运行的过程中就不需要花费时间去创建这些bean，速度就快了许多。