jvm的划分与微服务注册/追踪/监控

jvm发展历史：serial（单线程jvm）--cms（经典分代jvm）---G1（最新jvm，采用元空间，不再分代）

jvm 现在主流用的是jdk8，所以还是需要了解分代的，jvm主要分为：方法区（也叫永久代），堆，虚拟机栈，本地方法栈，指令控制区

其中 方法区 主要是存储类型的信息，常量定义与值，方法的定义，常量池等，堆主要就是存储对象的，虚拟机栈一般都是存储方法内局部变量，操作，动态链接等，本地方法栈就是存储本地方法的，如指令控制区就是存储指令的

其中栈的寿命随着线程的生死而生死，就是出栈和入栈，所以不需要垃圾回收，但是堆就不一样了，方法区的不回收

那么是怎么回收的，算法主要三种，标记清除（一般不用，因为会产生大量内存碎片，导致以后大对象设置不进去，导致频繁的minor GC，也就是新生代垃圾回收），标记复制（新生代回收策略，根据这个策略堆分为eden区，两个survior区，old区，其中对象是放在eden区和其中一个survior区，大小比我8:1，当回收时会标记，然后把所有的不清除的对象然后复制到另外一个survior区，然后把这两个区的的空间清空），标记整理（老年代回收策略，把所有不清除的对象都移动到一边，然后沿着边沿删除其他所有，老年代对象多和大不适合复制）

问题来了：另外一个survior区空间会有补偿机制么？有，老年代补偿，并且经过多次回收遗留的对象会根据你设置的次数来移动到老年代

垃圾回收是怎么判断对象需要回收的呢？GC-root方法，先在永久代找到GC root类，然后找对象到达gC-root对象是否有路径，没有路径的就需要删除掉

 

今天学到的微服务：

 配置中心config-server （手动调用刷新配置接口，然后区gitlab拉最新配置，然后发送到bus，config-client订阅bus消息更新配置）与消息中心spring cloud bus的结合，使所有订购配置中心的都能收到通过消息中心来获取配置的更新，其中配置中心可以接入gitlab，其中gitlab的关键字密码等可以采用加密方式存储

微服务追踪sleuth与elk结合，实现分布式日志收集

微服务追踪sleuth（监控框子）与zipkin（追踪展示与具体实现），rabbitMq（收集zipkin client数据），es（持久化存储数据）