1.AOP原理：
那Spring中AOP是怎么实现的呢？Spring中AOP的有两种实现方式：
1、JDK动态代理
2、Cglib动态代理
JDK动态代理:
1.能够继承静态代理的全部优点.并且能够实现代码的复用.
2.动态代理可以处理一类业务.只要满足条件 都可以通过代理对象进行处
理.
3.动态代理的灵活性不强.
4.JDK 的动态代理要求代理者必须实现接口, , 否则不能生成代理对象. .
Cglib动态代理：
1.不管有无接口都可以创建代理对象.
2.cglib创建的代理对象是目标对象的子类.
2.请问执行下面代码的输出结果是什么？
try {
throw new ExceptionB("b");
} catch (ExceptionA e) {
System.out.println("ExceptionA");
} catch (Exception e) {
System.out.println("Exception");
}
这个代码的运行结果是找不到类ExceptionB, BExceptionA
3.List、Set、Map是否继承Collection 接口？
答：List，Set是，Map不是。
4.Collection和Collections的区别？
Collection是集合类的上级接口，继承与他有关的接口主要有List和Set
Collections是针对集合类的一个帮助类，他提供一系列静态方法实现对各种集合的搜索、排序、线程安全等操作
5.SpringBoot的常用注解？
@SpringBootApplication：包含了@ComponentScan、@Configuration和@EnableAutoConfiguration注解。其中@ComponentScan让spring Boot扫描到Configuration类并把它加入到程序上下文。
@Configuration 等同于spring的XML配置文件；使用Java代码可以检查类型安全。
@EnableAutoConfiguration 自动配置。
@ComponentScan 组件扫描，可自动发现和装配一些Bean。
@Component可配合CommandLineRunner使用，在程序启动后执行一些基础任务。
@RestController注解是@Controller和@ResponseBody的合集,表示这是个控制器bean,并且是将函数的返回值直 接填入HTTP响应体中,是REST风格的控制器。
@Autowired自动导入。
@PathVariable获取参数。
@JsonBackReference解决嵌套外链问题。
@RepositoryRestResourcepublic配合spring-boot-starter-data-rest使用。
6.是否可以继承String类？
答案： 不可以，因为String类有final修饰符，而final修饰的类是不能被继承的，实现细节不允许改变。
7.String和StringBuilder、StringBuffer的区别？
String：适用于少量字符串操作的情况
StringBuilder:适用于单线程下在字符缓冲区进行大量操作的情况
StringBuffer:适用于多线程下在字符缓冲区进行大量操作的情况
在线程安全上，StringBuilder是线程不安全的，而StringBuffer是线程安全的。
运行速度方面，在这方面运行速度快慢为：StringBuilder>StringBuffer>String
8.两个对象值相同（x.equals(y)==true）,但却有可能有不同的hash code,这句话对不对？
答：对
9.你做过的mysql数据库优化有哪些？
sql语句优化
索引优化
加缓存
读写分离
分区
分布式数据库（垂直切分）
水平切分
10.写一个简单的排序算法
int[] ints = new int[]{998,123,456,1,5,6,9,3,24,8,10};
for (int i = 0; i < ints.length; i++) {
for (int j = 0; j < ints.length - i - 1; j++) {
int temp = ints[j];
if (temp > ints[j + 1]) {
ints[j] = ints[j+1];
ints[j+1] = temp;
}
}
}
for (int i : ints) {
System.out.println(i);
}
Java通过Executors提供四种线程池，分别为：
newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。
Eureka的工作原理以及它与ZooKeeper的区别
1、Eureka 简介：
Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。其中， Eureka 又可细分为 Eureka Server 和 Eureka Client。
1.基本原理
上图是来自eureka的官方架构图，这是基于集群配置的eureka；
- 处于不同节点的eureka通过Replicate进行数据同步
- Application Service为服务提供者
- Application Client为服务消费者
- Make Remote Call完成一次服务调用
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。
当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。
服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。
2.Eureka的自我保护机制
在默认配置中，Eureka Server在默认90s没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。
为了解决这个问题，Eureka 有自我保护机制，通过在Eureka Server配置如下参数，可启动保护机制
eureka.server.enable-self-preservation=true它的原理是，当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。
自我保护模式的架构哲学是宁可放过一个，决不可错杀一千
3. 作为服务注册中心，Eureka比Zookeeper好在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。
3.1 Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
3.2 Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
4. 总结
Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。不过Eureka目前1.X版本的实现是基于servlet的Java web应用，它的极限性能肯定会受到影响。期待正在开发之中的2.X版本能够从servlet中独立出来成为单独可部署执行的服务。