无端科技面试（部分）

￡神魔★判官ぃ 2023-10-04 13:19 17阅读 0赞

*  项目的服务之间通过什么协议交互的？1用Eureka有遇到过什么问题吗？往Eureka中注册一台机器，服务消费方会马上发现这台机器吗？为什么？2
 *  Hystrix熔断、限流的原理。什么时候用线程池，什么时候用Semaphore?3 大致思想：用线程池粒度大，每次都开启一个单独线程运行，开销更大。而信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。
 *  Netty用的是tcp方式还是http方式？协议是自己定的吗？是怎么定的，包含哪些信息？这个协议有加密方案，或者校验机制吗？Netty处理请求时存在线程安全的问题吗？参考答案：@sharable注解的ChannelHandler必须是线程安全的，因为它会被多个Channel的Pipeline共享，会被多线程并发调用4
 *  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 _9]。默认为dubbo 协议 ↩︎
2.  [彗安金科Java面试（部分）][Java]  
    [spring-cloud-eureka服务注册与发现][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 常见问题汇总及注意事项][Eureka]：已停止的微服务不注销或注销有延迟 ↩︎
3.  [Hystrix 服务的隔离策略对比，信号量与线程池隔离的差异][Hystrix]  
    [Hystrix 分布式系统限流、降级、熔断框架from阿里云开发者社区][Hystrix _from]：  
    线程隔离：把执行依赖代码的线程与请求线程分离  
    信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请）。  
    如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离，降低开销。  
    信号量模式从始至终都只有请求线程自身，是同步调用模式。。。由于没有线程的切换，开销非常小。  
    当请求的服务网络开销比较大的时候，或者是请求比较耗时的时候，我们最好是使用线程隔离策略，这样的话，可以保证大量的容器(tomcat)线程可用，不会由于服务原因，一直处于阻塞或等待状态，快速失败返回。  
    信号量：适合你的访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问，但是像这种访问，系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获timeout类似的问题 ↩︎
4.  [netty channel的线程安全性与@Sharable][netty channel_Sharable] ↩︎

[dubbo _9]: https://blog.csdn.net/xiaojin21cen/article/details/79834222
[Java]: https://blog.csdn.net/qq_23204557/article/details/115154884?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522162081751916780255238063%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=162081751916780255238063&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_v2~rank_v29-1-115154884.nonecase&utm_term=Eureka
[spring-cloud-eureka]: https://www.cnblogs.com/wuzhenzhao/p/9466752.html
[Eureka]: https://xie.infoq.cn/article/343d27713e8333a023b9d2feb
[Hystrix]: https://my.oschina.net/u/867417/blog/2120713
[Hystrix _from]: https://developer.aliyun.com/article/716550
[netty channel_Sharable]: https://www.cnblogs.com/silyvin/p/9593368.html