无端科技面试（部分）

• 项目的服务之间通过什么协议交互的？¹用Eureka有遇到过什么问题吗？往Eureka中注册一台机器，服务消费方会马上发现这台机器吗？为什么？²
• Hystrix熔断、限流的原理。什么时候用线程池，什么时候用Semaphore?³ 大致思想：用线程池粒度大，每次都开启一个单独线程运行，开销更大。而信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。
• Netty用的是tcp方式还是http方式？协议是自己定的吗？是怎么定的，包含哪些信息？这个协议有加密方案，或者校验机制吗？Netty处理请求时存在线程安全的问题吗？参考答案：@sharable注解的ChannelHandler必须是线程安全的，因为它会被多个Channel的Pipeline共享，会被多线程并发调用⁴
• G1里仍然有分代吗？答案：（from《深入理解JAVA虚拟机》第3版）

在G1收集器出现之前的所有其他收集器，包括CMS在内，垃圾收集的目标范围要么是整个新生代（Minor GC），要么就是整个老年代（Major> GC），再要么就是整个Java堆（Full GC）。而G1跳出了这个樊笼，它可以面向堆内存任何部分来组成回收集（Collection> Set，一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。。。虽然G1也仍是遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理

与CMS的“标记-清除”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部（两个Region之间）上看又是基于“标记-复制”算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片

---

1. dubbo 支持的9种协议。默认为dubbo 协议 ↩︎

2. 彗安金科Java面试（部分）
   spring-cloud-eureka服务注册与发现中的“为什么要有自我保护机制”：
   众所周知，Eureka在CAP理论当中是属于AP ， 也就说当产生网络分区时，Eureka保证系统的可用性，但不保证系统里面数据的一致性，举个例子。当发生网络分区的时候，Eureka-Server和client端的通信被终止，server端收不到大部分的client的续约，这个时候，如果直接将没有收到心跳的client端自动剔除，那么会将可用的client端剔除，这不符合AP理论，所以Eureka宁可保留也许已经宕机了的client端， 也不愿意将可以用的client端一起剔除。 从这一点上，也就保证了Eureka程序的健壮性，符合AP理论。自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。　
   　　默认情况下，每隔 一 段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。但是，如果短时间内丢失大量的实例心跳，便会触发eureka server的自我保护机制，比如在开发测试时，需要频繁地重启微服务实例，但是我们很少会把eureka server一起重启（因为在开发过程中不会修改eureka注册中心），当一分钟内收到的心跳数大量减少时，会触发该保护机制。
   。。。
   从警告中可以看到，eureka认为虽然收不到实例的心跳，但它认为实例还是健康的，eureka会保护这些实例，不会把它们从注册表中删掉。
   　　该保护机制的目的是避免网络连接故障，在发生网络故障时，微服务和注册中心之间无法正常通信，但服务本身是健康的，不应该注销该服务
   Eureka 常见问题汇总及注意事项：已停止的微服务不注销或注销有延迟 ↩︎

3. Hystrix 服务的隔离策略对比，信号量与线程池隔离的差异
   Hystrix 分布式系统限流、降级、熔断框架from阿里云开发者社区：
   线程隔离：把执行依赖代码的线程与请求线程分离
   信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请）。
   如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离，降低开销。
   信号量模式从始至终都只有请求线程自身，是同步调用模式。。。由于没有线程的切换，开销非常小。
   当请求的服务网络开销比较大的时候，或者是请求比较耗时的时候，我们最好是使用线程隔离策略，这样的话，可以保证大量的容器(tomcat)线程可用，不会由于服务原因，一直处于阻塞或等待状态，快速失败返回。
   信号量：适合你的访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问，但是像这种访问，系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获timeout类似的问题 ↩︎

4. netty channel的线程安全性与@Sharable ↩︎