(原创)Pipeline1-Getting-Started-With-Pipeline

前言(笔者自己添加部分)

最好的资料莫过于新版官方文档，旧文档不再维护，旧文档请参见这里。
所以本文其实是翻译并实践学习pipeline，对应的pdf文档，已上传到csdn

笔者是独立翻译实验，不允许转载

本文直接从Pipeline开始，如果对Jenkins不熟悉，请参见Jenkins官方文档或者本系列的第一章Installing Jenkins。

Pipeline

本章将会学习Jenkins Pipeline的所有特性，从运行Pipeline到写Pipeline代码，甚至扩展到Pipeline本身。

本章可以被Jenkins各个水平的用户使用，但是初学者可能要参考下本书”Using Jenkins”的章节去理解本章的一些专有名词。

如果还没有熟悉最基本的Jenkins技术和特点，请从”Getting Started with Jenkins”开始。

What is Jenkins Pipeline?

Jenkins Pipeline(或者简单用一个大写字母P代替”Pipeline”)是一套插件，这套插件支持实现和整合持续集成pipelines(continuous delivery pipelines)到Jenkins中。

持续集成Pipeline (continuous delivery pipelines)是一个程序自动进行的过程, 用您的用户和客户的版本控制权获取软件。对软件的每次更改(在源代码管理中提交)经过一个复杂的过程, 用它的方式发布软件(release)。这个过程包括以一个可靠地可重复的方式去构建软件，就像通过测试和发布(deployment)的多个步骤去构建(build)软件过程一样。

Pipeline提供一套可扩展的工具集，用代码去模型化简单到复杂的(simple-to-complex)发布pipelines，代码使用Pipeline Domain Specific Language(DSL)语法。

通常, Jenkins Pipeline的定义被写入文本文件 (称为 Jenkinsfile)，文件被放到项目的源代码管理存储库中[3: Source Control Management]。这是Pipeline代码(Pipeline-as-Code)的基础；把持续集成作为应用的一部分用版本控制，并且像其他代码一样可以review。创建Jenkinsfile有很多好处：

  • 自动为所有的分支和pull requests创建Pipelines
  • 在Pipeline中进行代码审查和迭代(review/iteration)
  • Pipeline的审核和跟踪
  • Pipeline唯一的真相源 [4: en.wikipediaorg/wiki/Single_Source_of_Truth]，可以由项目的多个成员查看和编辑。
    定义Pipeline的语句，要么在web UI中，要么在一个Jenkinsfile文件中，一般认为最好的体验是，定义Pipeline在Jenkinsfile文件中，并且放到源代码版本控制中(例如git，svn等)。
    这是一个Jenkinsfile文件例子：

① agent表明Jenkins要为Pipeline的这部分分配一个执行器和工作空间。

② stage表明是这个Pipeline的一个stage。

③ steps这个stage将要运行的一个步骤。

④ sh执行给与的shell语句。

⑤ junit是一个Pipeline步骤，Junit插件提供用来搜集测试报告。

Why Pipeline?

Jenkins基本上是一个自动化引擎, 它支持许多自动化模式。Pipeline添加了一套强有力的自动化工具集到Jenkins，支持从简单持续集成到综合持续集成的用例，到Pipeline。通过将一系列相关任务模型化，用户能充分利用Pipeline许多特性的优势。

  • Code：Pipeline是用代码实现，能做版本控制，可以给团队编辑/检查/迭代Pipeline的能力。
  • Durable：Pipeline可以在计划的和未计划的Jenkins主机重启中不受影响。
  • Pausable：Pipeline在继续运行之前，可以选择停止/等待输入或者批准。
  • Versatile：Pipeline能满足现实世界复杂的持续集成需求，包括并行执行fork/join/loop。
  • Extensible：Pipeline插件支持定制化的扩展到它自己的DSL[2: Domain-Specific Language]。

虽然Jenkins一直允许基本形式的链接自由式Jobs[5: Additional plugins have been used to implement complex behaviors utilizing Freestyle Jobs such as the Copy Artifact, Parameterized Trigger, and Promoted Builds plugins]，一起执行顺序任务, Pipeline使这个概念成为Jenkins的一流插件。
基于Jenkins可扩展的核心价值，Pipeline同样是可扩展的。
下图是一个持续集成的例子，可以很容易被模型化。

Pipeline 关键字

Step

一个独立的任务；一般来说steps告诉Jenkins做什么。例如执行shell命令，用sh执
行make：sh ‘make’。当插件扩展Pipeline DSL，这意味着插件能执行一个新的step。

Node

Pipeline执行的大多数工作是在一个或多个声明的Node的上下文中完成的。限制Node

步骤内的工作有两点：

(1).将块中包含的steps，通过向Jenkins添加项来运行队列.一旦一个执行器在一个节点上是空闲的, 这些steps就会运行。

(2).创建工作区 (特定于该特定Pipeline的目录)，在工作区里，工作能被完成。

注意：

取决于你的Jenkins配置，经过一段时间的不活动时期之后，一些工作区不能被自
动清除。可以查看JENKINS-2111得到更多的信息。

Stage

Stage是定义整个Pipeline概念上子集的一个步骤，例如”Build”，”Test”，和”Deploy”，这被许多插件使用来可视化或者表现pipeline状态/进度。[5: Blue Ocean, Pipeline Stage View plugin]

开始Pipeline(Getting Started with Pipeline)

Jenkins Pipeline是一套支持持续集成的插件。Pipeline提供扩展的工具，通过Pipeline DSL去模型化简单到复杂的代码发布Pipeline。

本部分介绍一些Jenkins Pipeline的基本概念，例如基本的定义，用Pipeline执行任务。

前提条件

使用Jenkins Pipeline，你会需要：

  • Jenkins 2.x或者更高版本(更老版本1.642.3可能可以，但是不推荐)
  • Pipeline插件[6: Pipeline plugin]

想知道怎样安装和管理，请参见 Managing Plugins。

定义Pipeline

Pipeline脚本是用Groovy语言撰写。于是本文会介绍一些相关的Groovy语法，理解Groovy是有帮助的，但并不是必需的。

一个基本的Pipeline能按照以下两种方式创建：

  • Jenkins web UI上直接输入脚本
  • 创建一个Jenkinsfile文件，这个能被放到代码版本控制软件中。

用任意方法定义Pipeline的语法是相同的, 但Jenkins支持将Pipeline直接输入到 web UI 中, 通常认为最好的做法是定义在Jenkinsfile的Pipeline, Jenkins将直接从源代码管理加载。

在web UI中定义一个Pipeline

在web UI中创建一个基本的Pipeline。跟随以下步骤：

  • 点击Jenkins首页上的”New Item”。

  • 为Pipeline输入一个名字，选择Pipeline，然后点击OK。

注意：Jenkins用Pipeline的名字在硬盘上创建目录。包含空格的Pipeline名字可能会有bugs，脚本并不支持包含空格的路径。

  • 在Script区域，输入一个Pipeline，然后点击Save。

  • 点击”Build Now”去运行Pipeline。

  • 点击”build History”下的#1，然后点击Console Output去查看Pipeline完整的输出。

上面的例子展示了一个成功的Pipeline运行情况，用了两步。

① node分配一个执行器和工作空间。

② echo在Console Output输出字符串。

在SCM中定义一个Pipeline

复杂的Pipeline很难在Pipeline配置区域去写和维护。为了让这个更容易一些，Pipeline同样可以用文本编辑器写并放到版本控制中，通过Pipeline Script from SCM选项，Jenkins可以装载Jenkinsfile文件。

要做到这一点，当定义一个Pipeline时，选择”Pipeline Script from SCM”选项。

随着”Pipeline Script from SCM”选项被选择，在Jenkins界面上，你不能直接输入任何Groovy代码；你只能输入一个源代码路径，从这个路径可以找到pipeline文件。当更新代码库的时候，一个新的编译被触发，只要Pipeline被配置使用SCM polling触发。

提示：

Jenkinsfile的第一行应该是#!/usr/bing/env groovy，这样文本编辑器，IDEs，GitHub等可以按照Groovy代码来语法高亮Jenkinsfile文件。

内建文档(Built-in Documentation)

随着Pipeline一起发布的内建的文档，使得创建复杂的Pipelines更加容易。内建的文档可以根据安装在Jenkins实例中的插件，被自动生成和更新。

内建的文档可以通过链接被找到: localhost:8080/pipeline-syntax/。假设你已经有了一个正运行在本地8080端口上的实例。同样的文档可以连接到这里，通过任何项目的左边菜单”Pipeline Syntax”。

代码段生成器(Snippet Generator)

内建的代码段生成器(Snippet Generator)功能对于以下功能很有帮助，创建独立步骤地代码，发现插件提供的新步骤，对于一个特定的步骤实验不同的参数。

代码段生成器是动态填充的, 其中列出了可供Jenkins使用的步骤。可用的步骤数取决于安装的插件, 它显式地公开了Pipeline可使用的步骤。

使用代码生成器，生成步骤

(1).导航到Pipeline Syntax链接。

(2).在Sample Step下达菜单中，选择需要的步骤。

(3).使用Sample Step下拉菜单下面的动态区域去配置选定的步骤。

(4).点击Gemerate Pipeline Script生成一个代码段，拷贝到Pipeline中。

存取选定步骤的附加信息，点击Help按钮()上图红色箭头所指部分。

Global Variable Reference

除了代码段生成器(Snippet Generator)只能生成步骤之外，Pipeline同样提供了一个内建的”Global Variable Reference”。像代码段生成器(Snippet Generator)一样，它也是被插件动态生成的。不像代码段生成器(Snippet Generator)的是，Global Variable Reference仅仅包含Pipeline或者插件提供的变量文档，只对Pipeline有效。

Pipeline默认提供的变量有：

env

环境变量可以被Pipeline脚本，例如env.PATH或者env.BUILD_ID。可以到Global Variable Reference寻找，到目前为止，完整的，最新的，Pipeline中可以使用的变量列表。

params

将为Pipeline定义的所有参数公开为只读映射, 例如:params.MY_PARAM_NAME

currentBuild

可以被用来发现当前正在执行的Pipeline的相关信息，例如currentBuild.result，currentBuild.displayName等等。可以到Global Variable Reference寻找，到目前为止，完整的，最新的，可以用的currentBuild列表。

Further Reading

本章节仅仅只说出了Jenkins Pipeline能做的一小部分，但已经为你提供了足够多的基础，去开始实验Jenkins实例。

下一节Jenkinsfile，更多的Pipeline步骤将被讨论。

Additional Resources

  • Pipeline Steps Reference, 包含发布插件提供的所有步骤
  • Pipeline Examples，可拷贝社区版的Pipeline例子集合。

参考资料：

  1. https://jenkins.io/doc/book/pipeline/
  2. https://en.wikipedia.org/wiki/Domain-specific_language
  3. https://en.wikipedia.org/wiki/Version_control
  4. https://en.wikipedia.org/wiki/Single_source_of_truth
  5. https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Stage+View+Plugin
  6. https://plugins.jenkins.io/workflow-aggregator
  7. ../managing/plugins.pdf

展开全文 >>

Java OOM ERROR

Java内存溢出(OOM异常完全指南),原文见:http://www.jianshu.com/p/2fdee831ed03
作者CHEN川是从这里翻译来的:https://plumbr.io/outofmemoryerror
笔者是独立翻译实验，不允许转载

java.lang.OutOfMemoryError:Java heap space

Java应用程序被允许使用有限的内存。这个限制在程序开始运行的时候就被说明了。为了便于处理，Java内存被分成两个区域，分别称为：堆内存/堆空间(Heap space)和永久代(Permgen, Permanent Generation)。

这两个区域的大小可以在JVM(Java虚拟机)启动时通过参数-Xmx和-XX:MaxPermSize设置。如果你不显示指定大小，将使用特定平台的默认值。

当应用程序试图添加更多的数据到堆空间区域，却没有足够空间，此时java.lang.OutOfMemoryError: Java heap space error将被触发。注：系统可能有许多未使用的物理内存，但是当JVM到达堆空间大小限制的时候，java.lang.OutOfMemoryError: Java heap space error异常仍然会被抛出。
注意(编者加)：上面的JVM内存模型是JDK7的模型，在JDK8中已经移除了永久代，取而代之的是MetaSpace(主要存放类的元数据)。

原因分析(What is causing it)：

触发java.lang.OutOfMemoryError: Java heap space error异常的常见原因：应用程序需要XXL号的堆内存，但是却提供了一个s号的堆内存。也就是说：应用程序需要比它所能得到的更大的堆内存。其它引发OutOfMemory的原因更加复杂，也有可能是程序原因。

  • 使用/数据量峰值：应用程序在设计之初要考虑处理大量的用户和大量的数据。当大量的用户或者数据突然到达峰值，并且超过了预期的阈值，以前在峰值到达之前功能正常的操作将会停止，并且触发java.lang.OutOfMemoryError异常。
  • 内存泄漏：一种特殊的编程错误将会导致应用程序持续消耗更多的内存。每一次有内存泄漏功能的应用程序使用，都将留下一些对象在java堆空间中，随着时间的推移，泄露的对象消耗越来越多的java堆空间，就触发了我们熟悉的java.lang.OutOfMemoryError异常。

示例

简单示例

第一个应用程序非常简单–下面的java代码试图申请一个2M的数组。当编译并以一个12M(java -Xmx12m OOM)的堆内存运行的时候，将会失败，并且提示：Java.lang.OutOfMemoryError: Java heap space message。如果给与13M的堆内存，程序将运行很好。

1
2
3
4
5
6
class OOM {
   static final int SIZE=2*1024*1024;
   public static void main(String[] a) {
     int[] i = new int[SIZE];
   }
}

运行结果如下：
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at OOM_heapspace.main(OOM_heapspace.java:7)

内存泄漏示例

在Java中，当开发者创建和使用新的对象，例如new Integer(5)，他们不用自己分配内存–这个工作是Java虚拟机(JVM)来做的。在整个应用程序生命周期中，JVM会定期检查，内存中的哪些对象仍然在使用，哪些对象没有继续使用。不再使用的内存对象会被回收，并被重新分配和再使用。这个过程称之为垃圾回收（Garbage Collection）。JVM执行这个功能的模块被称为Garbage Collector(GC)。

Java的自动内存管理依赖于GC定期的寻找不再使用的对象并且移除他们。 简单来说，我们可以说：在Java中的内存泄漏是这样一种情况，一些对象不再被应用程序使用，但是GC却没办法识别他们。因此这些不再被使用的对象仍然无限期的保留在Java的堆空间中。这样的堆积最终将触发java.lang.OutOfMemoryError: Java heap space异常。
很容易新建一个java程序来满足内存泄露的定义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class KeylessEntry {
  static class Key {
    Integer id;
    Key(Integer id) {
      this.id = id;
    }

    @Override
    public int hashCode() {
      return id.hashCode();
    }
  }

  public static void main(String[] args) {
    Map m = new HashMap();
      while (true)
        for (int i = 0; i < 10000; i++)
          if (!m.containsKey(new Key(i)))
            m.put(new Key(i), "Number:" + i);
    }
}

当执行上面的代码，我们可能会认为程序会一直跑下去，没有任何问题，认为存储在缓存中的Map将扩展到10000个元素，再往下，所有的Key都已经在HashKey中存在了。然而，实际情况是Key class的元素并不包含equals这个方法的实现。

因此，随着时间的继续，泄露内存代码的持续运行，会导致消耗大量java堆空间。当持续占满所有可用的堆空间，并且GC不能清除的时候，就会触发java.lang.OutOfMemoryError: Java heap space异常。

解决方案非常简单–添加equals()方法的实现，这样代码就能很好的运行。

1
2
3
4
5
6
7
8
@Override
public boolean equals(Object o) {
  boolean response = false;
    if (o instanceof Key) {
      response = (((Key)o).id).equals(this.id);
    }
    return response;
}

解决方案

某些情况，我们分配给JVM堆空间的内存数量不能满足程序运行的需求。此时，我们应该分配更多的堆空间，看本文的结尾如何做。

然而，在更多情况下，提供更多堆空间并不能解决问题。例如应用程序有内存泄漏，添加更多的堆内存只会推迟java.lang.OutOfMemoryError: Java heap space异常。另外，增加堆空间数量也会增加GC暂停的次数进而影响应用程序的吞吐量或者延迟(latency).

如果希望解决Java堆空间的潜在问题，而不是掩盖问题，那么我们需要搞清楚代码的哪一部分负责申请内存。换句话说，必须回答以下问题：

  • 哪些对象占据了堆空间的大部分
  • 这些对象在源代码的位置

在这一点上，一定要确信搞清楚。下面是一个大致的大纲，这个大纲将帮助我们回答上面的问题：

  • 获得安全许可，以便从JVM执行heap dump。”Dumps”基本上来说是对堆内容的快照，这些内容是我们可以分析的。这些快照包含了关键信息，例如密码，信用卡号码等等，由于安全原因，我们甚至不太可能获取这些快照。
  • 在合适的时刻得到dump文件。错误的时间得到一些dumps文件，堆dump文件包含大量的无用内容。另一方面，每一个堆dump包含了jvm的所有内容，因此不要做太多次的dump操作，否则客户也需要面对性能问题。
  • 找到一台能够读取dump文件的机器。在开始执行JVM问题调查的时候，例如一个8GB的堆，我们需要一台超过8GB去分析堆内容。至于用来分析dump文件的软件(我们推荐Eclipse MAT，当然也有其它许多优秀的软件，例如JProfiler/YourKit)。注：到现在为止Jprofiler10为最新版，找不到合适的license。因此使用Jprofiler9.2，是好用的。
  • 检查堆空间最大消费者的GC根目录的路径。我们已经做过这件事情，有一个单独的文章，请参见这里。对于初学者来说有些困难，但是实践将会使我们理解结构和机制。
  • 接下来，我们需要搞清楚代码中，哪些代码申请了大量内存。如果对自己的应用程序的源代码有很好了解的话，那么几次搜索就能做完这件事情。

解决方案就是增大堆空间
-Xmx1024m

再例如所有下面的配置具有同样功能，因为我们可以使用g/G/m/M/k/K。例如所有如下配置都是相同的，最大堆空间是1GB：

1
2
3
4
java -Xmx1073741824 com.mycompany.MyClass
java -Xmx1048576k com.mycompany.MyClass
java -Xmx1024m com.mycompany.MyClass
java -Xmx1g com.mycompany.MyClass

java.lang.OutOfMemoryError:GC overhead limit exceeded

JRE(Java Runtime Environment)包含了一个自带/内嵌的GC(Garbage Collection)程序。在许多其它编程语言中，开发者需要自己申请和释放内存。

另一方面，Java程序只需要申请内存即可。当内存中一个空间不再使用的时候，一个独立的称作GC的进程将清除这些不再使用的内存。GC是如何检测内存中特殊区域，详细情况请见：Garbage Collection Handbook，但是我们应该信任GC能做好它的工作(内存回收)。

java.lang.OutOfMemoryError: GC overhead limit exceeded异常将被触发，当应用程序消耗了所有可用的内存，GC还在不停的清除内存，并且清除内存一直失败。

原因分析：

java.lang.OutOfMemoryError: GC overhead limit exceeded异常，是JVM发出的一个信号，表明：应用程序花费了太多时间在做内存回收的工作，回收结果却不好。默认情况下，JVM将会报错，如果花费超过98%时间在执行GC操作，却仅仅回收了不到2%的内存。


如果GC overhead limit不存在，将会发生什么事情？java.lang.OutOfMemoryError: GC overhead limit exceeded异常只有在这种情况下才会被触发，经过几次GC循环操作之后，只释放了2%的内存。这意味着只有少量的堆空间能被清除，这些空间将会被很快再次用掉，强迫GC再次重新开始清除进程。这就形成了一个恶性循环，CPU100%被用于GC操作，没办法做其他事情了。应用的终端用户感觉非常慢-通常毫秒级别完成的操作，现在却需要数分钟才能完成。

于是”java.lang.OutOfMemoryError: GC overhead limit exceeded”提示可以看做”fail fast”规则一个非常棒的例子。

实例

下面的例子，我们将创建一个GC overhead limit exceeded异常，通过初始化一个MAP，通过无限循环添加key-value对到map中。

1
2
3
4
5
6
7
8
9
class Wrapper {
  public static void main(String args[]) throws Exception {
    Map map = System.getProperties();
    Random r = new Random();
    while (true) {
      map.put(r.nextInt(), "value");
    }
  }
}

你有可能猜到，这段代码可能不能很好的结束。确实，当用下列配置运行这段代码的时候，

1
2
3
java -Xmx100m -XX:+UseParallelGC Wrapper
java -Xmx10m -XX:+UseParallelGC Wrapper
java -Xmx20m -XX:+UseParallelGC Wrapper

错误信息如下(使用JDK7)：
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Hashtable.rehash(Hashtable.java:402)
at java.util.Hashtable.addEntry(Hashtable.java:426)
at java.util.Hashtable.put(Hashtable.java:477)
at GC_ole.main(GC_ole.java:11)
当使用如下参数java -Xmx2m -XX:+UseParallelGC Wrapper，错误信息如下：
Exception in thread “main” java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.Hashtable.put(Hashtable.java:541)
at GC_ole.main(GC_ole.java:11)

不久，我们就将看到java.lang.OutOfMemoryError: GC overhead limit exceeded异常。但是如果我们配置不同的堆空间大小或者不同的GC算法，结果会有不同。例如，用如下方式在ubuntu16.04，用Hotspot1.7.0_80运行：
java -Xmx10m -XX:+UseParallelGC Wrapper
我们将看到如下错误：
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Hashtable.rehash(Hashtable.java:471)
at java.util.Hashtable.put(Hashtable.java:532)
at GC_ole.main(GC_ole.java:11)

使用以下GC算法：-XX:+UseConcMarkSweepGC 或者-XX:+UseG1GC，启动命令如下：
java -Xmx100m -XX:+UseConcMarkSweepGC Wrapper
java -Xmx100m -XX:+UseG1GC Wrapper
得到的结果是这样的：
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “main”
错误已经被默认的异常处理程序捕获，并且没有任何错误的堆栈信息输出。
以上这些变化可以说明，在资源有限的情况下，你根本无法无法预测你的应用是怎样挂掉的，什么时候会挂掉，所以在开发时，你不能仅仅保证自己的应用程序在特定的环境下正常运行。

解决方案

如果我们仅仅想去掉java.lang.OutOfMemoryError: GC overhead limit exceeded这个消息，添加下列到启动脚本里面就可以做到：

-XX:-UseGCOverheadLimit

烈建议不要这样做–应该修复解决这个问题，而不是将这个不可避免的问题推迟或者延后；因为应用程序将会把内存用尽。错误信息也变成了更加熟悉的java.lang.OutOfMemoryError: Java heap space而已。

某些情况下，GC overhead limit exceeded异常被触发，因为申请的内存不能满足程序运行的需要。此时，应该申请更多的内存–看本文末尾如何做到这一点。例如应用程序存在内存泄漏，将推迟java.lang.OutOfMemoryError: Java heap space异常。另外增加内存将增加GC暂停的时间长度，影响到应用程序的吞吐量和延迟等。

如果希望解决Java堆空间的潜在问题，而不是掩盖问题，那么我们需要搞清楚代码的那一部分负责申请内存。换句话说，必须回答以下问题：

  • 哪些对象占据了堆空间的大部分
  • 这些对象在源代码的位置

在这一点上，一定要确信搞清楚。下面是一个大致的大纲，这个大纲将帮助我们回答上面的问题：

  • 通过安全检查，以从JVM执行heap dump。”Dumps”基本上来说是对内容的快照。这些快照包含了关键信息，例如密码，信用卡号码等等，由于安全原因，我们甚至不太可能获取这些快照。
  • 在合适的时刻得到dump文件。错误的时间得到一些dumps文件，堆dump文件包含大量的无用内容。另一方面，每一个堆dump包含了jvm的所有内容，因此不要做太多次的dump操作，否则客户也需要面对性能问题。
  • 找到一台能够读取dump文件的机器。在开始执行JVM问题调查的时候，例如一个8GB的堆，我们需要一台超过8GB去分析对内容。至于用来分析dump文件的软件(我们推荐Eclipse MAT，当然也有其它许多优秀的软件，例如JProfiler/YourKit)。注：到现在为止Jprofiler10为最新版，找不到合适的license。因此使用Jprofiler9.2，是好用的。具体请参见百度云盘jprofiler目录。
  • 检查堆空间最大消费者的GC根目录的路径。我们这个分析，有一个单独的文章，请参见这里。对于初学者来说有些困难，但是实践将会是我们理解结构和机制。
  • 接下来，我们需要搞清楚代码中，哪些代码申请了大量内存。如果对自己的应用程序的源代码有很好的了解的话，那么几次搜索就能做完这件事情。

java.lang.OutOfMemoryError:Permgen space

Java应用程序只被允许使用有限的内存。确切使用的内存数量只能在程序开始运行时才能知道。Java内存被分成不同的区域，如下图所示：


注：此为JDK7的jvm内存模型。
上图所有的区域包括永久代都是在JVM开始运行的时候被设定。如果不设置，将会使用特定平台的默认值。
java.lang.OutOfMemoryError: PermGen space消息表明：内存中的永久代区域已经被用完了。

原因分析

要想理解java.lang.OutOfMemoryError: PermGen space的原因，我们需要知道这块内存区域的用途：
为了实践目的，永久代包含大多数的类定义，也就是类/方法的名字和字段，全局不可变变量池，对象数组，类相关的对象数组，实时编译优化等。
从上面的定义，我们可以看出，永久代的大小取决于类申明的数量和装载的类的数量。因为，我们可以说：java.lang.OutOfMemoryError: PermGen space的主要原因：要么太多的类，要么太大的类被分配到了永久带空间。

实例

简单实例

综上所述，永久带空间的使用是和加载到jvm的类的数量强相关的。下面是一个简明的例子：

1
2
3
4
5
6
7
8
9
10
11
12
import javassist.ClassPool;
public class MicroGenerator {
  public static void main(String[] args) throws Exception {
    for (int i = 0; i < 100_000_000; i++) {
      generate("com.myown.demo.Generated" + i);
    }
  }
  public static Class generate(String name) throws Exception {
    ClassPool pool = ClassPool.getDefault();
      return pool.makeClass(name).toClass();
  }
}

在这个示例中，通过循环逐个生成运行时类。类的生成是javassist库负责。

运行上面的代码将持续生成新类并把他们的定义装载到永久代空间，直到空间被全部使用，java.lang.OutOfMemoryError: PermGen space异常就会被触发。
实际测试发现(Ubuntu16.04 JDK7，设置-XX:MaxPermSize=512m,否则内存空间占据太多),报错如下：
Exception in thread “main”
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “main”
为什么不是java.lang.OutOfMemoryError: PermGen space异常,从监控看，PermGen空间确实满了，heap有剩余。

重新部署示例

再说一个更加复杂和更加实际的例子，在程序重新部署发布的时候，我们经历一次java.lang.OutOfMemoryError: PermGen space异常的发生。当我们重新发布应用程序的时候，我们希望GC能清除以前的旧的已经装载的类，并重新装载新版本的类。

不幸的是，许多第三方类和资源的处理，例如线程，JDBC驱动或者文件系统处理，不能卸载旧类。这也意味着：每一次重新发布，所有先前版本的类仍然存在于永久代空间，并且每次重新发布都会生成几十M的垃圾数据。

想象一个例子，应用使用JDBC连接到一个关系型数据库。当应用开始的时候，代码初始化JDBC驱动去连接数据库。根据说明，JDBC驱动会注册他自己为java.sql.DriverManager。注册会存储一个引用，这个引用指向到一个DrvierManager实例的静态字段。

现在，当从服务器上卸载应用程序的时候，java.sql.DriverManager仍将持有那个驱动程序的引用，进而持有用于加载应用程序的classloader的一个实例的引用，通常会占有数十兆的永久代空间。这个classloader现在仍然引用着应用程序的所有类。这意味着经历过几次重新部署，就会触发java.lang.OutOfMemoryError: PermGen space错误。

解决方案

  • .解决初始化时的OutOfMemoryError

当OutOfMemoryError因永久代耗尽被触发的时候(应用程序启动的时候)，解决方案非常简单。应用程序需要更多的空间去家在所有的类到永久代区域。我们增大永久代的大小，提示应用程序增大永久带空间。-XX:MaxPermSize相似的参数：

java -XX:MaxPermSize=512m com.yourcompany.YourClass

上面的配置告诉JVM，永久代最大空间可以到512M。

  • 解决重新发布的OutOfMemoryError

当重新发布应用的时候，OutOfMemoryError恰好发生了，说明应用程序遭遇了classloader泄露。此时我们应该执行堆dump分析–是用类似如下命令去执行堆dump的工作:

jmap -dump:format=b,file=dump.hprof

然后用熟悉的工具去分析dump文件。如果是第三方库的原因，可以去Google/StackOverflow检查下是否是一个已知问题，如是已知问题，可以下载一个补丁或者解决方案。如果是自己代码的问题，需要及时修改。

  • 解决运行时OutOfMemoryError

首先你需要检查是否允许GC从PermGen卸载类，JVM的标准配置相当保守，只要类一创建，即使已经没有实例引用它们，其仍将保留在内存中，特别是当应用程序需要动态创建大量的类但其生命周期并不长时，允许JVM卸载类对应用大有助益，你可以通过在启动脚本中添加以下配置参数来实现：

-XX:+CMSClassUnloadingEnabled

默认情况下，这个配置是未启用的，如果你启用它，GC将扫描PermGen区并清理已经不再使用的类。但请注意，这个配置只在UseConcMarkSweepGC的情况下生效，如果你使用其他GC算法，比如：ParallelGC或者Serial GC时，这个配置无效。所以使用以上配置时，请配合：

-XX:+UseConcMarkSweepGC

如果你已经确保JVM可以卸载类，但是仍然出现内存溢出问题，那么你应该继续分析dump文件，使用以下命令生成dump文件：

jmap -dump:file=dump.hprof,format=b

当你拿到生成的堆转储文件，并利用像Eclipse Memory Analyzer Toolkit这样的工具来寻找应该卸载却没被卸载的类加载器，然后对该类加载器加载的类进行排查，找到可疑对象，分析使用或者生成这些类的代码，查找产生问题的根源并解决它。

java.lang.OutOfMemoryError:Metaspace

Java应用程序只被允许使用有限的内存。确切使用的内存数量只能在程序开始运行时才能知道。Java内存被分成不同的区域，如下图所示：


上面所有的区域，包括元数据区域，都是在JVM启动的时候被设定。如果没有指定，那么特定平台的默认数据将被使用。
java.lang.OutOfMemoryError: Metaspace预示着内存中的元数据空间消耗殆尽。

原因分析

如果不是Java新手，那么你可能熟悉另外一个称作PermGen的Java内存管理的概念。从Java8开始，内存模型有显著的改变。一个新的被称为Metaspace的内存区域被引进，PermGen被移除了。这个改变有多种原因，包括但不限于以下：

  • 永久代(PermGen)的大小很难预测。这直接导致了要么触发java.lang.OutOfMemoryError: Permgen size异常，要么浪费资源。
  • GC效率的提升改进，使得并发类数据重新申请内存不再进行GC暂停(GC pause)和指定元数据遍历。
  • 支持进一步的优化，例如G1并发类卸载。
    如果熟悉PermGen，那么也知道它的作用–在java8以前，所有类的名字、字段、方法，字节方法，变量池，JIT优化等都是存储在PermGen中，现在都在Metaspace中。

正如你所看到的，元空间大小的要求取决于加载的类的数量以及这种类声明的大小。 所以很容易看到java.lang.OutOfMemoryError: Metaspace主要原因：太多的类或太大的类加载到元空间。

实例

正如前面解释的，Metaspace是和加载的类的数量密切相关。下面的代码是一个简单明了的说明：

1
2
3
4
5
6
7
8
public class Metaspace {
  static javassist.ClassPool cp = javassist.ClassPool.getDefault();
    public static void main(String[] args) throws Exception{
      for (int i = 0; ; i++) {
        Class c = cp.makeClass("com.myown.demo.Generated" + i).toClass();
      }
    }
}

在这个例子中，源代码在运行时遍历循环生成类。所有生成的类定义都位于Metaspace中。类生成的工作交由javassist负责。

代码持续生成新类，并把它们的定义装载到Metaspace中，直到元数据空间被全部使用，java.lang.OutOfMemoryError: Metaspace异常被触发。当用-XX:MaxMetaspaceSize=64m在Ubuntu16.04.3, java 1.8.0_151，一共加载了66126个类，程序才挂掉。试验得出的完整错误信息如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Exception in thread "main" javassist.CannotCompileException: by java.lang.OutOfMemoryError: Metaspace
    at javassist.ClassPool.toClass(ClassPool.java:1085)
    at javassist.ClassPool.toClass(ClassPool.java:1028)
    at javassist.ClassPool.toClass(ClassPool.java:986)
    at javassist.CtClass.toClass(CtClass.java:1079)
    at Metaspace.main(Metaspace.java:8)
Caused by: java.lang.OutOfMemoryError: Metaspace
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at javassist.ClassPool.toClass2(ClassPool.java:1098)
    at javassist.ClassPool.toClass(ClassPool.java:1079)
    ... 4 more

解决方案

第一个解决方案，毫无疑问：OutOfMemoryError是因为Metaspace。如果应用程序将metaspace消耗殆尽，我们可以增大Metaspace的空间。更改程序配置，按照如下进行：

-XX:maxMetaspaceSize=512m

上面的配置告诉JVM:Metaspace空间最大允许到512MB。

另外一个解决方案初一看更加简单。我们可以移除Metaspace的大小限制(删除这个参数即可)。但是这样做，将会导致沉重的交换负担，会导致内存分配失败。

你可以通过修改各种启动参数来“快速修复”这些内存溢出错误，但你需要正确区分你是否只是推迟或者隐藏了java.lang.OutOfMemoryError的症状。如果你的应用程序确实存在内存泄漏或者本来就加载了一些不合理的类，那么所有这些配置都只是推迟问题出现的时间而已，实际也不会改善任何东西。

java.lang.OutOfMemoryError:Unable to create new native thread

Java应用程序天然支持多线程的。这意味着java实现的程序能一次做几件事情(几乎同时)。甚至只有一个cpu–在从一个窗口拉数据到另外一个窗口的时候，视频同时也在后台不停的播放，因为可以同时执行多个操作。

一个思考多线程的方式就是把他们认为是我们能提交任务给他们执行的工人。如果只有一个工人，那么他/她一次只能做一件事情。但是如果有很多工人的话，他们就能根据你的命令同时做事。

就像这些工人都在物理世界，JVM中的线程完成自己的工作也是需要一些空间的，当有足够多的线程却没有那么多的空间时就会像这样：


java.lang.OutOfMemoryError: Unable to create new native thread意味着： Java应用已经到了它所能启动的线程的极限。

原因分析

当JVM请求操作系统去创建一个新的线程，操作系统却不能再申请一个新的线程，此时OutOfMemoryError(java.lang.OutOfMemoryError: Unbale to crate new thread))就被触发。线程数目的确切数字是依赖于平台的。如果想找到线程数目的限制，可以运行下面将要提到的例子。

一般来说， 引发java.lang.OutOfMemoryError: Unable to create new native thread异常有以下几种情况：

  • 运行在jvm中的应用程序需要一个新的java线程。
  • JVM向OS请求创建一个新的线程。
  • OS试图创建一个新的线程，这个线程需要申请内存。
  • OS拒绝分配内存给线程，因为32位Java进程已经耗尽内存地址空间(2-4GB内存地址已被命中)或者OS的虚拟内存已经完全耗尽。
  • java.lang.OutOfMemoryError: Unable to create new native thread异常被触发。

实例

下面的代码循环创建和开始线程。当运行代码时，很快就到达操作系统的限制，java.lang.OutOfMemoryError: Unable to create new native thread异常被触发。

1
2
3
4
5
6
7
8
9
while(true){
  new Thread(new Runnable(){
    public void run() {
      try {
        Thread.sleep(10000000);
      } catch(InterruptedException e) { }        
    }
  }).start();
}

确切的线程数目限制是依赖于平台的，例如Windows，Linux和Mac OS X如下：

64-bit Mac OS X 10.9, Java 1.7.0_45 – JVM dies after #2031 threads have been created
64-bit Ubuntu Linux, Java 1.7.0_45 – JVM dies after #31893 threads have been created
64-bit Windows 7, Java 1.7.0_45 – due to a different thread model used by the OS,250000,交换文件到10G,程序非常慢
通过一个小测试可以知道线程的极限数目。
实际Ubuntu16.04.3 x64, Java 1.8.0_151–JVM dies after 11658 threads have been created
Exception in thread “main” java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at OOM_TestThread.main(OOM_TestThread.java:9)
实际的ulimit限制有6w+(63812)，也修改过idea的VM的Xmx,由原先的750m调整到6168，效果也是一样。
lj@lj-HP-ProBook-640-G1:~/Downloads/source/java-study/javaUnversailTest$ ulimit -a
max user processes (-u) 63812
也使用命令行运行，实际数值差不多，都在116xx左右，差别不大。

解决方案

有时，我们可以通过增加OS级限制，绕过Unable to create new native thread issue错误。例如你限制了JVM可在用户空间创建的线程数，那么你可以检查并增加这个限制：
lj@lj-HP-ProBook-640-G1:~/Downloads$ ulimit -a
core file size (blocks, -c) 0
…… …… …… …… ……
max user processes (-u) 63812
到达线程限制预示着程序错误。当应用产生数以千计的线程，有时会产生异常可怕的错误–并没有太多的应用需要巨量的线程数目。
解决这个问题的一个方式：执行线程dump，可以理解当时的状况。

java.lang.OutOfMemoryError:Out of swap space

java程序在启动的时候是有内存限制的。这个限制是用参数-Xmx和其他相似的参数说明。有些情况下，JVM要求的内存比可用的物理内存还大，OS(操作系统)开始交换内存的内容到硬盘。


java.lang.OutOfMemoryError: Out of swap space异常表明：交换空间同样耗尽，并且新的内存申请失败，因为缺少物理内存和交换空间。

原因分析

当从堆空间申请字节内存失败，并且堆空间也耗尽的时候，java.lang.OutOfMemoryError: Out of swap space异常将被触发。该错误消息中包含分配失败的大小（以字节为单位）和请求失败的原因。

这个问题往往发生在Java进程已经开始交换的情况下，现代的GC算法已经做得足够好了，当时当面临由于交换引起的延迟问题时，GC暂停的时间往往会让大多数应用程序不能容忍。

java.lang.OutOfMemoryError:Out of swap space?往往是由操作系统级别的问题引起的，例如：

  • 操作系统配置的交换空间不足。
  • 系统上的另一个进程消耗所有内存资源。

还有可能是本地内存泄漏导致应用程序失败，比如：应用程序调用了native code连续分配内存，但却没有被释放回操作系统。

解决方案

解决这个问题有几个办法，通常最简单的方法就是增加交换空间，不同平台实现的方式会有所不同，比如在Linux下可以通过如下命令实现：
先用free -m查看交换空间定义的是多少
swapoff -a –关闭交换区
dd if=/dev/zero of=swapfile bs=1024 count=655360–根目录下创建一个名为swapfile,大小640M
mkswap swapfile–将swapfile设置为swap区
swapon swapfile–启用交换区

Java GC会扫描内存中的数据，如果是对交换空间运行垃圾回收算法会使GC暂停的时间增加几个数量级，因此你应该慎重考虑使用上文增加交换空间的方法。

如果你的应用程序部署在JVM需要同其他进程激烈竞争获取资源的物理机上，建议将服务隔离到单独的虚拟机中
但在许多情况下，您唯一真正可行的替代方案是：

  • 升级机器以包含更多内存
  • 优化应用程序以减少其内存占用

当您转向优化路径时，使用内存转储分析程序来检测内存中的大分配是一个好的开始。

java.lang.OutOfMemoryError:Requested array size exceeds VM limit

Java对应用程序可以分配的最大数组大小有限制。不同平台限制有所不同，但通常在1到21亿个元素之间。


当你遇到Requested array size exceeds VM limit错误时，意味着你的应用程序试图分配大于Java虚拟机可以支持的数组。

原因分析

该错误由JVM中的native code抛出。 JVM在为数组分配内存之前，会执行特定于平台的检查：分配的数据结构是否在此平台中是可寻址的。

你很少见到这个错误是因为Java数组的索引是int类型。 Java中的最大正整数为2 ^ 31 - 1 = 2,147,483,647。 并且平台特定的限制可以非常接近这个数字，例如：我的环境上(64位macOS，运行Jdk1.8)可以初始化数组的长度高达2,147,483,645（Integer.MAX_VALUE-2）。如果再将数组的长度增加1到Integer.MAX_VALUE-1会导致熟悉的OutOfMemoryError：
Exception in thread “main” java.lang.OutOfMemoryError: Requested array size exceeds VM limit
但是，在使用OpenJDK 6的32位Linux上，在分配具有大约11亿个元素的数组时，您将遇到Requested array size exceeded VM limit的错误。 要理解你的特定环境的限制，运行下文中描述的小测试程序。

示例

1
2
3
4
5
6
7
8
for (int i = 3; i >= 0; i--) {
    try {
        int[] arr = new int[Integer.MAX_VALUE-i];
        System.out.format("Successfully initialized an array with %,d elements.\n", Integer.MAX_VALUE-i);
    } catch (Throwable t) {
        t.printStackTrace();
    }
}

该示例重复四次，并在每个回合中初始化一个长原语数组。 该程序尝试初始化的数组的大小在每次迭代时增加1，最终达到Integer.MAX_VALUE。 现在，当使用Hotspot 7在64位Mac OS X上启动代码片段时，应该得到类似于以下内容的输出：
java.lang.OutOfMemoryError: Java heap space
at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Java heap space
at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
注意，在出现Requested array size exceeded VM limit之前，出现了更熟悉的java.lang.OutOfMemoryError: Java heap space。 这是因为初始化2 ^ 31-1个元素的数组需要腾出8G的内存空间，大于JVM使用的默认值。

解决方案

java.lang.OutOfMemoryError:Requested array size exceeds VM limit可能会在以下任一情况下出现：
数组增长太大，最终大小在平台限制和Integer.MAX_INT之间
你有意分配大于2 ^ 31-1个元素的数组
在第一种情况下，检查你的代码库，看看你是否真的需要这么大的数组。也许你可以减少数组的大小，或者将数组分成更小的数据块，然后分批处理数据。
在第二种情况下，记住Java数组是由int索引的。因此，当在平台中使用标准数据结构时，数组不能超过2 ^ 31-1个元素。事实上，在编译时就会出错：error：integer number too large。

java.lang.OutOfMemoryError:Kill process or sacrifice child

为了理解这个错误，我们需要补充一点操作系统的基础知识。操作系统是建立在进程的概念之上，这些进程在内核中作业，其中有一个非常特殊的进程，名叫“内存杀手（Out of memory killer）”。当内核检测到系统内存不足时，OOM killer被激活，然后选择一个进程杀掉。哪一个进程这么倒霉呢？选择的算法和想法都很朴实：谁占用内存最多，谁就被干掉。如果你对OOM Killer感兴趣的话，建议你阅读参考资料2中的文章。


OOM Killer，
当可用虚拟虚拟内存(包括交换空间)消耗到让整个操作系统面临风险时，就会产生Out of memory:Kill process or sacrifice child错误。在这种情况下，OOM Killer会选择“流氓进程”并杀死它。

原因分析

默认情况下，Linux内核允许进程请求比系统中可用内存更多的内存，但大多数进程实际上并没有使用完他们所分配的内存。这就跟现实生活中的宽带运营商类似，他们向所有消费者出售一个100M的带宽，远远超过用户实际使用的带宽，一个10G的链路可以非常轻松的服务100个(10G/100M)用户，但实际上宽带运行商往往会把10G链路用于服务150人或者更多，以便让链路的利用率更高，毕竟空闲在那儿也没什么意义。

Linux内核采用的机制跟宽带运营商差不多，一般情况下都没有问题，但当大多数应用程序都消耗完自己的内存时，麻烦就来了，因为这些应用程序的内存需求加起来超出了物理内存（包括 swap）的容量，内核（OOM killer）必须杀掉一些进程才能腾出空间保障系统正常运行。就如同上面的例子中，如果150人都占用100M的带宽，那么总的带宽肯定超过了10G这条链路能承受的范围。

示例

当你在Linux上运行如下代码：

1
2
3
4
5
6
7
8
9
10
public static void main(String[] args){
    List<int[]> l = new java.util.ArrayList();
    for (int i = 10000; i < 100000; i++) {
        try {
            l.add(new int[100000000]);
        } catch (Throwable t) {
            t.printStackTrace();
        }
    }
}

在Linux的系统日志中/var/log/kern.log会出现以下日志：
Jun 4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child
Jun 4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB
注意：你可能需要调整交换文件和堆大小，否则你将很快见到熟悉的Java heap space异常。在作者的测试用例中，使用-Xmx2g指定的2g堆，并具有以下交换配置：

解决方案

解决这个问题最有效也是最直接的方法就是升级内存，其他方法诸如：调整OOM Killer配置、水平扩展应用，将内存的负载分摊到若干小实例上….. 我们不建议的做法是增加交换空间。当您回想起 Java 是一种垃圾收集的语言时, 这个解决方案似乎已经不那么有利可图了。现代 GC 算法在物理内存中运行时效率很高, 但是在处理交换空间分配时, 效率很差。交换可以增加几个数量级的GC暂停的长度, 因此在跳转到此解决方案之前, 您应该三思而后行。

展开全文 >>

(原创)查询log中每小时或者指定小时，错误类型的数量

In a log file with contents as

假设一个log文件名为application.log，且格式为：(实测中发现有可能因为log文件数据不正常，导致统计结果不一致)
2017-11-22 07:29:45.489 INFO com.aaa.bbb.ccc.dubboservice.impl.BingGenTfoTaskServiceImpl [DubboServerHandler-1.2.3.4:18080-thread-199] zzzzAaaAaaaaaa:结束生成aaaaaa,zzzzzz是:56661
2017-11-22 07:29:45.489 ERROR com.aaaaa.aaa.aaa.dubboservice.impl.BingGenTfoTaskServiceImpl [DubboServerHandler-1.2.3.4:18080-thread-199] zzzzAaaAaaaaaa:结束生成bbbbbb,qwerty是:56661
……

执行脚本如下：

1
2
3
4
5
6
7
8
9
lj@lj-HP-ProBook-640-G1:~/linux-study$ ./getstatic_byhour.sh application.log  ERROR
没有收到第三个参数，将搜集所有小时的数据
---all ERROR hava times:3113
2017-11-22 07 have ERROR times:30
2017-11-22 08 have ERROR times:60
......   
2017-11-24 15 have ERROR times:10
lj@lj-HP-ProBook-640-G1:~/linux-study$ ./getstatic_byhour.sh application.log  ERROR '2017-11-24 09'
2017-11-24 09 have ERROR times:60

实现脚本如下：

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
lj@lj-HP-ProBook-640-G1:~/Downloads/source/linux-study$ cat getstatic_byhour.sh
#!/bin/bash
log_name=""
error_style=""
by_hour=""
function printhelp()
{
    echo 'there is no para.invoke sample is:'
    echo ''$0' log_folder|log_name  error_style [2017-11-24 09]'
    echo 'if there is no hour, will display every hour'
}
if [ $# -lt 2 ]; then
    printhelp
    exit
else
    if [ "$1" ]; then
        log_name="$1"
    fi
    if [ "$2" ]; then
        error_style="$2"
    fi
    if [ "$3" ]; then
        by_hour="$3"
        strr=`grep -caP "^${by_hour}:\d{2}:\d{2}.\d{3} ${error_style}" ${log_name}`
        echo "${by_hour} have ${error_style} times:"${strr}
    else
        echo '没有收到第三个参数，将搜集所有小时的数据'
        by_hour=""
        strr=`grep -caP "^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3} ${error_style}" ${log_name}`
        echo "---all ${error_style} hava times:"${strr}
        grep -aP "\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3}" ${log_name} | awk -F':' '{print $1}' | uniq | sort > tempgrep.txt
        while read line
        do
            strr=`grep -caP "^${line}:\d{2}:\d{2}.\d{3} ${error_style}" ${log_name}`
            echo "${line} have ${error_style} times:"${strr}
        done < tempgrep.txt
        rm -f ./tempgrep.txt
    fi
fi
exit

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧<br><br>只做了一点微小的工作<br>谢谢大家