1、List、Hashmap遍历方式？for遍历时可以删除吗？
List
（1）For循环遍历list：
for(int i=0;i<list.size();i++){
if(list.get(i).equals("li"))
list.remove(i);
}
这是一种很常见的遍历方式，但是使用这种遍历删除元素会出现问题，原因在于删除某个元素后，list的大小发生了变化，而索引也在变化，所以会导致你在遍历的时候漏掉某些元素。比如当你删除第一个元素后，继续根据索引访问第二个元素后，因为删除的原因，后面的元素都往前移动了以为，所以实际访问的是第三个元素。因此，这种遍历方式可以用在读取元素，而不适合删除元素。
（2）增强for循环遍历list：
for(String x:list){
if(x.equals("li"))
list.remove(x);
}
这也是一种很常见的遍历方式，但是使用这种遍历删除元素也会出现问题，运行时会报ConcurrentModificationException异常。其实增强for循环是java语法糖的一种体现。增强for循环反编译得到字节码是Iterator遍历。
语法糖：
语法糖（Syntactic sugar），也译为糖衣语法，是由英国计算机科学家彼得·兰丁发明的一个术语，指计算机语言中添加的某种语法，这种语法对语言的功能没有影响，但是更方便程序员使用。语法糖让程序更加简洁，有更高的可读性。
java中的语法糖只存在于编译期, 在编译器将 .java 源文件编译成 .class 字节码时, 会进行解语法糖操作, 还原最原始的基础语法结构。这些语法糖包含条件编译、断言、Switch语句与枚举及字符串结合、可变参数、自动装箱/拆箱、枚举、内部类、泛型擦除、增强for循环、lambda表达式、try-with-resources语句、JDK10的局部变量类型推断等等。
异常是在next方法的checkForComodification中抛出，抛出的原因是modCount !=expectedModCount。这里的modCount是指这个list对象从呢我出来到现在被修改的次数，当调用list的add或者remove方法的时候，这个modCount都会自动增减；iterator创建的时候modCount被复制给了expectedModcount，但是调用list的add和remove方法的时候不会同时自动增减expectedModcount，这样就导致两个count不相等，从而抛出异常。如果删除的是倒数第二个元素却不会碰到异常
（3）iterator遍历遍历list删除：
Iterator<String> it = list.iterator();
while(it.hasNext()){
String x = it.next();
if(x.equals("li")){
it.remove();
}
}
这种方式是可以正常遍历和删除的。但是你可能看到上面代码感觉和增强for循环内部实现的代码差不多，其实差别就在于上面使用
一个使用list.remove(),一个使用it.remove()。
HashMap
（1）For循环遍历HashMap删除：
for(Map.Entry<Integer, String> entry : map.entrySet()){
Integer key = entry.getKey();
if(key % 2 == 0){
System.out.println("del key " + key);
map.remove(key);
System.out.println("key " + + key + " ok del");
}
遍历删除会报ConcurrentModificationException异常。
（2）增强for遍历HashMap删除：
Set keySet = map.keySet(); for(Integer key : keySet){ if(key % 2 == 0){ System.out.println("del key " + key); keySet.remove(key); System.out.println("key " + + key + " ok del"); } }
遍历删除会报ConcurrentModificationException异常。
（3）Iterator遍历HashMap删除：
Iterator<Map.Entry<Integer, String>> it = map.entrySet().iterator();
while(it.hasNext()){
Map.Entry<Integer, String> entry = it.next();
Integer key = entry.getKey();
if(key % 2 == 0){
System.out.println("del key " + key);
it.remove();
System.out.println("key " + + key + " ok del");
}
}
遍历无报错。
如果查询源代码以上的三种的删除方式都是通过调用HashMap.removeEntryForKey方法来实现删除key的操作。在removeEntryForKey方法内执行删除了key，modCount就会执行一次自增操作，此时modCount就与expectedModCOunt不一致了，上面三种remove实现中，只有第三种iterator的remove方法在调用完removeEntryForKey方法后同步了expectedModCount值与modCount相同，所以iterator方式不会抛出异常。
2、dubbo底层原理？
Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看， Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容，详见后面描述。
总体架构
Dubbo的总体架构，如图所示：
Dubbo框架设计一共划分了10个层，最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。 下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：
（1）服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。
（2）配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。
（3）服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
（4）服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。
（5）集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
（6）监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。
（7）远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
（8）信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
（9）网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
（10）数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。
根据官方提供的，对于上述各层之间关系的描述，如下所示：
（1）在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
（2）图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider、Consumer、Registry、Monitor划分逻辑拓普节点，保持统一概念。
（3）而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。
（5）Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
（6）而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina、Netty、Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
（7）Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
3、Springcloud使用了哪些组件？
（1）服务注册与发现——Netflix Eureka
（2）负载均衡——Netflix Ribbon
（3）断路器——Netflix Hystrix
（4）服务网关——Netflix Zuul
（5）分布式配置——Spring Cloud Config
（6）Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。
