Young Collection日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

2016-09-29T16:58:43.298+0800: 84662.983: [GC pause (G1 Evacuation Pause) (young)
   [Parallel Time: 39.5 ms, GC Workers: 13]
      [GC Worker Start (ms): Min: 84662997.2, Avg: 84662997.6, Max: 84662997.8, Diff: 0.6]
      [Ext Root Scanning (ms): Min: 1.0, Avg: 1.6, Max: 6.2, Diff: 5.2, Sum: 21.0]
      [Update RS (ms): Min: 8.1, Avg: 12.4, Max: 13.1, Diff: 5.0, Sum: 161.1]
         [Processed Buffers: Min: 9, Avg: 17.8, Max: 26, Diff: 17, Sum: 231]
      [Scan RS (ms): Min: 5.8, Avg: 6.2, Max: 6.3, Diff: 0.5, Sum: 80.2]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 18.4, Avg: 18.6, Max: 18.7, Diff: 0.3, Sum: 241.2]
      [Termination (ms): Min: 0.0, Avg: 0.2, Max: 0.2, Diff: 0.2, Sum: 2.1]
         [Termination Attempts: Min: 1, Avg: 149.4, Max: 197, Diff: 196, Sum: 1942]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 1.1]
      [GC Worker Total (ms): Min: 38.7, Avg: 39.0, Max: 39.3, Diff: 0.6, Sum: 506.8]
      [GC Worker End (ms): Min: 84663036.5, Avg: 84663036.5, Max: 84663036.6, Diff: 0.1]
   [Code Root Fixup: 0.1 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 1.1 ms]
   [Other: 17.8 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 1.9 ms]
      [Ref Enq: 0.1 ms]
      [Redirty Cards: 0.4 ms]
      [Humongous Register: 11.8 ms]
      [Humongous Reclaim: 0.1 ms]
      [Free CSet: 1.1 ms]
   [Eden: 7968.0M(7968.0M)->0.0B(13.8G) Survivors: 0.0B->0.0B Heap: 31.9G(96.0G)->24.3G(96.0G)]

GC pause (G1 Evacuation Pause) (young) - 表示此时GC暂停是YGC。

[toc]

概述

  G1垃圾收集器（Garbage First）是一个并行的、并发的、面向服务器的垃圾收集器的垃圾收集器。G1在Oracle JDK 7 update 4 及以上版本中得到完全支持，它的长远目标时代替CMS收集器。相较于CMS，G1是一款压缩型的收集器，不会产生内存碎片；可以极高概率满足GC停顿时间，实现低停顿垃圾回收。G1优先回收存活数据较少的区域。存活数据少就表示里面的垃圾对象多，这也是名字 Garbage First 的由来。

案例一 Major GC和Minor GC频繁

服务情况：Minor GC每分钟100次 ，Major GC每4分钟一次，单次Minor GC耗时25ms，单次Major GC耗时200ms，接口响应时间50ms。

有时候，我们需要用拦截器对Request或者Response流里面的数据进行拦截，读取里面的一些信息，也许是作为日志检索，也许是做一些校验，但是当我们读取里请求或者回调的流数据后，会发现这些流数据在下游就无法再次被消费了，这里面是其实存在着两个潜在的坑。

  SpringMVC的核心就是DispatcherServlet，DispatcherServlet实质也是一个HttpServlet。DispatcherSevlet负责将请求分发，所有的请求都有经过它来统一分发。

  大致看下SpringMVC请求处理的流程：

  用户向服务器发送请求，请求会到DispatcherServlet，DispatcherServlet 对请求URL进行解析，得到请求资源标识符（URI），然后根据该URI，调用HandlerMapping获得该Handler配置的所有相关的对象（包括一个Handler处理器对象、多个HandlerInterceptor拦截器对象），最后以HandlerExecutionChain对象的形式返回。
  DispatcherServlet 根据获得的Handler，选择一个合适的HandlerAdapter。提取Request中的模型数据，填充Handler入参，开始执行Handler（Controller)。 在填充Handler的入参过程中，根据你的配置，Spring将帮你做一些额外的工作：

• HttpMessageConveter： 将请求消息（如Json、xml等数据）转换成一个对象，将对象转换为指定的响应信息
• 数据转换：对请求消息进行数据转换。如String转换成Integer、Double等
• 数据格式化：对请求消息进行数据格式化。 如将字符串转换成格式化数字或格式化日期等
• 数据验证： 验证数据的有效性（长度、格式等），验证结果存储到BindingResult或Error中

  Handler执行完成后，向DispatcherServlet 返回一个ModelAndView对象；根据返回的ModelAndView，选择一个适合的ViewResolver返回给DispatcherServlet；ViewResolver 结合Model和View，来渲染视图，最后将渲染结果返回给客户端。

  Spring Bean的加载依赖于BeanFactory，但实际使用时不会直接使用BeanFactory，而是采用ApplicationContext这个在BeanFactory基础上提供了扩展的接口:

1
2
3

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, 
    HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver {
    

  ApplicationContext接口具体的实现类常用的有：FileSystemXmlApplicationContet (从文件系统中读入Bean定义资源文件)、ClassPathXmlApplicationContext(从Classpath类路径中读入Bean定义资源文件)和XmlWebApplicationContext(从Web容器如Tomcat等中读入Bean定义资源文件)等。

使用 Spring Boot 工程时默认 web 容器是 Tomcat，但是可以根据需要进行修改，例如使用 Jetty 或者 Undertow。只需要排除spring-boot-starter-web包中的spring-boot-starter-tomcat，然后添加其它的容器即可，例如spring-boot-starter-jetty。

[toc]

背景

接收到公司业务部门的开发反馈，应用在升级公司内部框架后，UAT（预生产）环境接口性能压测不达标。
升级前压测报告：

升级后压测报告：

在机器配置（1C4G）相同的情况下，吞吐量从原来的 53.9/s 下降到了 6.4/s，且 CPU 负载较高。

并且开发反馈从公司全链路监控系统 SkyWalking 中查询到的链路信息可以得知大部分请求 Feign 调用的耗时不太正常（390ms），而实际被调用的下游服务响应速度很快（3ms）。

PROPAGATION_REQUIRES_NEW：原有事务A新起事务B，事务B中的commit和rollback不会影响外部事务A的commit和rollback，相互独立，如果事务B抛出异常，肯定会影响外事务A的。

PROPAGATION_NESTED：表示嵌套事务，看如下示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

ServiceA {  
    /** 
     * 事务属性配置为 PROPAGATION_REQUIRED 
     */  
    @Transactional(propagation=Propagation.REQUIRED) // 1
    void methodA() {
        insertData(); //2
        try {
            ServiceB.methodB();   //3
        } catch (SomeException) {  
            // 执行其他业务, 如 ServiceC.methodC();   //5
        }
        updateData(); //6
    }  
}

ServiceB {

    @Transactional(propagation=Propagation.NESTED)
    void methodB(){
        //
        updateData(); //4
    }
}

在上面的1，将开起新事务A，2的时候会插入数据，此时事务A挂起，没有commit，3的时候，使用PROPAGATION_NESTED传播，将在3点的时候新建一个savepoint保存2插入的数据，不提交。
如果methodB出现异常，将回滚4的操作，不影响2的操作，同时可以处理后面的5,6逻辑，最后一起commit: 2,5,6；
如果methodB没有出现异常，那么将一起commit: 2,4,6。

转载自：https://blog.csdn.net/AlbertFly/article/details/149974109

当使用 kill -9（SIGKILL）终止 Java 进程时，SpringApplicationShutdownHook 和其他所有 Shutdown Hook 都不会执行。

以下是详细分析：

1. kill -9 的行为特性

信号类型：-9 发送的是 SIGKILL 信号
操作系统行为：

• 立即强制终止进程，不通知应用程序
• 跳过所有正常的清理流程（包括 JVM 的 Shutdown Hook）
• 操作系统直接回收进程资源