朝林最后一天

今天是我最后一天在朝林广场上班。

天气非常好，如同我来这个公司的那天。中午找了几个要好的朋友一起吃了顿便饭，算是告别吧！下午做了我唯一的一次业务+技术的分享，算是对我一段时间以来工作的总结和对负责系统未来的展望。

在这一年中学到了很多。在增长见识的同时视野变得开阔，这对以后的生活和工作有极大的帮助。我想我需要做出改变了，不知不觉已经毕业三年，时间不算短。期间有过努力拼搏，也曾偶尔懈怠。对比身边那些被人羡慕的人，我觉得自己的努力还差的很远。偶尔早起，在餐厅偶遇，总是感叹像他们那个位置的人还是如此拼搏，自己又有何理由懈怠呢？我想我的问题不是没有上进心，而是没有持之以恒的决心，总是间断。现在要去一个新的环境重新开始，也算是给自己找个重新开始的理由吧！妈妈常说：“吃的苦中苦，方为人上人”，虽然一直记在心头，却总没有吃的吃苦。现在我想是时候了，不论是外部环境的必然性还是内心深处的自我告诫。

走的时候，朋友相送，竟无语相对。相信以后再见，必然是另一种心境。在此祝愿朋友们家庭幸福，事业更上层楼。

How Jekyll works

What is Jekyll?

Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.

Example Jekyll websites

What does Jekyll do?

Jekyll is installed as a ruby gem local computer. Once installed you can call jekyll serve in the terminal in a directory and provided that directory is setup in a way jekyll expects, it will do magic stuff like parse markdown/textile files, compute categories, tags, permalinks, and construct your pages from layout templates and partials.

Once parsed, Jekyll stores the result in a self-contained static _site folder. The intention here is that you can serve all contents in this folder statically from a plain static web-server.

You can think of Jekyll as a normalish dynamic blog but rather than parsing content, templates, and tags on each request, Jekyll does this once beforehand and caches the entire website in a folder for serving statically.

Jekyll is Not Blogging Software.

Jekyll is a parsing engine

Jekyll does not come with any content nor does it have any templates or design elements. This is a common source of confusion when getting started. Jekyll does not come with anything you actually use or see on your website - you have to make it.

Why Should I Care?

Jekyll is very minimalistic and very efficient. The most important thing to realize about Jekyll is that it creates a static representation of your website requiring only a static web-server. Traditional dynamic blogs like Wordpress require a database and server-side code. Heavily trafficked dynamic blogs must employ a caching layer that ultimately performs the same job Jekyll sets out to do; serve static content.

Therefore if you like to keep things simple and you prefer the command-line over an admin panel UI then give Jekyll a try.

Developers like Jekyll because we can write content like we write code:

• Ability to write content in markdown or textile in your favorite text-editor.
• Ability to write and preview your content via localhost.
• No internet connection required.
• Ability to publish via git.
• Ability to host your blog on a static web-server.
• Ability to host freely on GitHub Pages.
• No database required.

How Jekyll Works

Heads up! The following is a complete but concise outline of exactly how Jekyll works. Core concepts are introduced in rapid succession without code examples. This information is not intended to specifically teach you how to do anything, rather it is intended to give you the full picture relative to what is going on in Jekyll-world. Learning these core concepts should help you avoid common frustrations and ultimately help you better understand the code examples contained throughout Jekyll-Bootstrap.

Initial Setup

After installing jekyll you’ll need to format your website directory in a way jekyll expects. Jekyll-bootstrap conveniently provides the base directory format.

The Jekyll Application Base Format

Jekyll expects your website directory to be laid out like so:

_config.yml
_includes
_layouts
    default.html
    post.html
_posts
    20011-10-25-open-source-is-good.markdown
    20011-04-26-hello-world.markdown
_site
index.html
assets
    css
        style.css
    javascripts

_config.yml Stores configuration data.

_includes This folder is for partial views.

_layouts This folder is for the main templates your content will be inserted into. You can have different layouts for different pages or page sections.

_posts This folder contains your dynamic content/posts. the naming format is required to be @YEAR-MONTH-DATE-title.MARKUP@.

_site This is where the generated site will be placed once Jekyll is done transforming it.

assets This folder is not part of the standard jekyll structure. The assets folder represents any generic folder you happen to create in your root directory. Directories and files not properly formatted for jekyll will be left untouched for you to serve normally.

(read more: http://jekyllrb.com/docs/usage/)

Jekyll Configuration

Jekyll supports various configuration options that are fully outlined here: http://jekyllrb.com/docs/configuration/

Content in Jekyll

Content in Jekyll is either a post or a page. These content “objects” get inserted into one or more templates to build the final output for its respective static-page.

Posts and Pages

Both posts and pages should be written in markdown, textile, or HTML and may also contain Liquid templating syntax. Both posts and pages can have meta-data assigned on a per-page basis such as title, url path, as well as arbitrary custom meta-data.

Working With Posts

Creating a Post
Posts are created by properly formatting a file and placing it the _posts folder.

Formatting

A post must have a valid filename in the form YEAR-MONTH-DATE-title.MARKUP and be placed in the _posts directory. If the data format is invalid Jekyll will not recognize the file as a post. The date and title are automatically parsed from the filename of the post file. Additionally, each file must have YAML Front-Matter prepended to its content. YAML Front-Matter is a valid YAML syntax specifying meta-data for the given file.

Order

Ordering is an important part of Jekyll but it is hard to specify a custom ordering strategy. Only reverse chronological and chronological ordering is supported in Jekyll.

Since the date is hard-coded into the filename format, to change the order, you must change the dates in the filenames.

Tags

Posts can have tags associated with them as part of their meta-data. Tags may be placed on posts by providing them in the post’s YAML front matter. You have access to the post-specific tags in the templates. These tags also get added to the sitewide collection.

Categories

Posts may be categorized by providing one or more categories in the YAML front matter. Categories offer more significance over tags in that they can be reflected in the URL path to the given post. Note categories in Jekyll work in a specific way. If you define more than one category you are defining a category hierarchy “set”. Example:

---
title :  Hello World
categories : [lessons, beginner]
---

This defines the category hierarchy “lessons/beginner”. Note this is one category node in Jekyll. You won’t find “lessons” and “beginner” as two separate categories unless you define them elsewhere as singular categories.

Working With Pages

Creating a Page

Pages are created by properly formatting a file and placing it anywhere in the root directory or subdirectories that do not start with an underscore.

Formatting

In order to register as a Jekyll page the file must contain YAML Front-Matter. Registering a page means 1) that Jekyll will process the page and 2) that the page object will be available in the site.pages array for inclusion into your templates.

Categories and Tags

Pages do not compute categories nor tags so defining them will have no effect.

Sub-Directories

If pages are defined in sub-directories, the path to the page will be reflected in the url. Example:

people
    bob
        essay.html

This page will be available at http://yourdomain.com/people/bob/essay.html

Recommended Pages

• index.html
  You will always want to define the root index.html page as this will display on your root URL.
• 404.html
  Create a root 404.html page and GitHub Pages will serve it as your 404 response.
• sitemap.html
  Generating a sitemap is good practice for SEO.
• about.html
  A nice about page is easy to do and gives the human perspective to your website.

Templates in Jekyll

Templates are used to contain a page’s or post’s content. All templates have access to a global site object variable: site as well as a page object variable: page. The site variable holds all accessible content and metadata relative to the site. The page variable holds accessible data for the given page or post being rendered at that point.

Create a Template
Templates are created by properly formatting a file and placing it in the _layouts directory.

Formatting
Templates should be coded in HTML and contain YAML Front Matter. All templates can contain Liquid code to work with your site’s data.

Rending Page/Post Content in a Template
There is a special variable in all templates named : content. The content variable holds the page/post content including any sub-template content previously defined. Render the content variable wherever you want your main content to be injected into your template:

<body>
  <div id="sidebar"> ... </div>
  <div id="main">
    {{content}}
  </div>
</body>

Sub-Templates

Sub-templates are exactly templates with the only difference being they define another “root” layout/template within their YAML Front Matter. This essentially means a template will render inside of another template.

Includes

In Jekyll you can define include files by placing them in the _includes folder. Includes are NOT templates, rather they are just code snippets that get included into templates. In this way, you can treat the code inside includes as if it was native to the parent template.

Any valid template code may be used in includes.

Using Liquid for Templating

Templating is perhaps the most confusing and frustrating part of Jekyll. This is mainly due to the fact that Jekyll templates must use the Liquid Templating Language.

####What is Liquid?

Liquid is a secure templating language developed by Shopify. Liquid is designed for end-users to be able to execute logic within template files without imposing any security risk on the hosting server.

Jekyll uses Liquid to generate the post content within the final page layout structure and as the primary interface for working with your site and post/page data.

Why Do We Have to Use Liquid?

GitHub uses Jekyll to power GitHub Pages. GitHub cannot afford to run arbitrary code on their servers so they lock developers down via Liquid.

Liquid is Not Programmer-Friendly.

The short story is liquid is not real code and its not intended to execute real code. The point being you can’t do jackshit in liquid that hasn’t been allowed explicitly by the implementation. What’s more you can only access data-structures that have been explicitly passed to the template.

In Jekyll’s case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins. Both of which cannot be supported by GitHub Pages.

As a programmer - this is very frustrating.

But rather than look a gift horse in the mouth we are going to suck it up and view it as an opportunity to work around limitations and adopt client-side solutions when possible.

My personal stance is to not invest time trying to hack liquid. It's really unnecessary from a programmer's perspective. That is to say if you have the ability to run custom plugins (i.e. run arbitrary ruby code) you are better off sticking with ruby. Toward that end I've built Mustache-with-Jekyll which is now abandoned =/. You should use http://ruhoh.com instead =D.

Static Assets

Static assets are any file in the root or non-underscored subfolders that are not pages. That is they have no valid YAML Front Matter and are thus not treated as Jekyll Pages. Static assets should be used for images, css, and javascript files.

How Jekyll Parses Files

Remember Jekyll is a processing engine. There are two main types of parsing in Jekyll.

• Content parsing.
• This is done with textile or markdown.
• Template parsing.
• This is done with the liquid templating language.

And thus there are two main types of file formats needed for this parsing.

Post and Page files.
All content in Jekyll is either a post or a page so valid posts and pages are parsed with markdown or textile.
Template files.
These files go in _layouts folder and contain your blogs templates. They should be made in HTML with the help of Liquid syntax. Since include files are simply injected into templates they are essentially parsed as if they were native to the template.

Arbitrary files and folders.

Files that are not valid pages are treated as static content and pass through Jekyll untouched and reside on your blog in the exact structure and format they originally existed in.

Formatting Files for Parsing.

We’ve outlined the need for valid formatting using YAML Front Matter. Templates, posts, and pages all need to provide valid YAML Front Matter even if the Matter is empty. This is the only way Jekyll knows you want the file processed.

YAML Front Matter must be prepended to the top of template/post/page files:

---
layout: post
category : pages
tags : [how-to, jekyll]
---
... contents ...

Three hyphens on a new line start the Front-Matter block and three hyphens on a new line end the block. The data inside the block must be valid YAML.

Configuration parameters for YAML Front-Matter is outlined here: A comprehensive explanation of YAML Front Matter

Defining Layouts for Posts and Templates Parsing.

The layout parameter in the YAML Front Matter defines the template file for which the given post or template should be injected into. If a template file specifies a layout parameter, it is effectively being used as a sub-template. That is to say loading a post file into a template file that refers to another template file will work in the way you’d expect; as a nested sub-template.

###How Jekyll Generates the Final Static Files.

Ultimately, Jekyll’s job is to generate a static representation of your website. The following is an outline of how that’s done:

1. Jekyll collects data.

   Jekyll scans the posts directory and collects all posts files as post objects. It then scans the layout assets and collects those and finally scans other directories in search of pages.

2. Jekyll computes data.
   Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one big site object that holds all the posts, pages, layouts, and respective metadata. At this stage your site is one big computed ruby object.

3. Jekyll liquifies posts and templates.
   Next jekyll loops through each post file and converts (through markdown or textile) and liquifies the post inside of its respective layout(s). Once the post is parsed and liquified inside the the proper layout structure, the layout itself is “liquified”.
   Liquification is defined as follows: Jekyll initiates a Liquid template, and passes a simpler hash representation of the ruby site object as well as a simpler hash representation of the ruby post object. These simplified data structures are what you have access to in the templates.

4. Jekyll generates output.
   Finally the liquid templates are “rendered”, thereby processing any liquid syntax provided in the templates and saving the final, static representation of the file.

Notes.

Because Jekyll computes the entire site in one fell swoop, each template is given access to a global site hash that contains useful data. It is this data that you’ll iterate through and format using the Liquid tags and filters in order to render it onto a given page.

Remember, in Jekyll you are an end-user. Your API has only two components:

1. The manner in which you setup your directory.
2. The liquid syntax and variables passed into the liquid templates.

All the data objects available to you in the templates via Liquid are outlined in the API Section of Jekyll-Bootstrap. You can also read the original documentation here: http://jekyllrb.com/docs/variables/

###Conclusion

I hope this paints a clearer picture of what Jekyll is doing and why it works the way it does. As noted, our main programming constraint is the fact that our API is limited to what is accessible via Liquid and Liquid only.

Jekyll-bootstrap is intended to provide helper methods and strategies aimed at making it more intuitive and easier to work with Jekyll =)

Thank you for reading this far.

Spring-MVC HandlerMapping HandlerAdapter简介

我们都知道spring-mvc的HandlerMapping是用来查找具体的Handler,HandlerAdapter是用来调用
查找到的Handler的具体方法的；下面我们就来分析一下HandlerMapping接口和HandlerAdapter接口
的具体实现：

JVM常用参数和调优

前言

下面所有内容都是针对Sun JDK1.6 JVM

jvm常用参数

• -Xms4096m：设置JVM堆初始大小为4096M

• -Xmx4096m：设置JVM堆最大为4096M

• -Xmn2g（-xx:NewSize=2g）：设置年轻代大小为2G。

• -Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为 256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。

• -xx:PermSize=128m 设置持久代的初始大小

• -XX:MaxPermSize=128m 设置持久代的最大值

• -XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4， 则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5

• -XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区 与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6

• -XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不 经过Survivor 区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代 对象会在Survivor区进行 多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

jvm性能调优

JVM性能调优的重点

• 内存分配

  为了满足性能指标，合理分配应用占用的堆内存空间和堆内各个区块的比例

• 垃圾收集

  根据应用的特点选择最合适的满足需求的垃圾收集器

JVM性能调优步骤

1. 添加JVM参数，打印垃圾收集日志并分析

   -Xloggc:filename

   -XX:+PrintGCDetails

   -XX:+PrintGCTimeStamps

2. 根据分析结果调整堆空间和堆内个部分的比例

3. 根据垃圾收集日志挑选符合自己应用的收集器

4. 根据垃圾收集日志继续调整堆空间和垃圾收集器参数

5. 根据垃圾收集日志重复3，4步骤

jvm参数详解

jvm参数

未完待续….

垃圾收集算法和Sun JVM 垃圾收集器简介

垃圾收集基础

Java 语言的一大特点就是可以进行自动垃圾回收处理，而无需开发人员过于关注系统资源，例如内存资源的释放情况。自动垃圾收集虽然大大减轻了开发人员的工作量，但是也增加了软件系统的负担。拥有垃圾收集器可以说是 Java 语言与 C++语言的一项显著区别。在 C++语言中，程序员必须小心谨慎地处理每一项内存分配，且内存使用完后必须手工释放曾经占用的内存空间。当内存释放不够完全时，即存在分配但永不释放的内存块，就会引起内存泄漏，严重时甚至导致程序瘫痪。

垃圾对象的判定

• 引用计数法

  引用计数器算法是给每个对象设置一个计数器，当有地方引用这个对象的时候，计数器+1，当引用失效的时候，计数器-1，当计数器为0的时候，JVM就认为对象不再被使用，是“垃圾”了。引用计数法实现简单，效率高；但是不能解决循环引用问问题（A对象引用B对象，B对象又引用A对象，但是A,B对象已不被任何其他对象引用），同时每次计数器的增加和减少都带来了很多额外的开销，所以在JDK1.1之后，这个算法已经不再使用了。

• 根搜索算法

  根搜索方法是通过一些称为“GC Roots”对象作为起点，从这些节点开始往下搜索，搜索通过的路径成为引用链（Reference Chain），当一个对象没有被GC Roots的引用链连接的时候，说明这个对象是没有被引用的，可以回收。
  GC Roots对象包括：

  a) 虚拟机栈（栈帧中的本地变量表）中的引用的对象。

  b) 方法区域中的类静态属性引用的对象。

  c) 方法区域中常量引用的对象。

  d) 本地方法栈中JNI（Native方法）的引用的对象。

垃圾收集算法

• 标记清除法(Mark-Sweep)

  标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段首先通过根搜素算法标记出被引用的对象，未被标记的对象就是可以被回收的垃圾对象。然后，在清除阶段，清除所有未被标记的对象。该算法最大的问题是回收垃圾对象后产生大量的内存碎片，导致以后大对象的内存分配困难，可能提前触发又一次的垃圾回收动作。

• 复制算法 (Copying)

  复制算法的基本思路是将现有的内存空间分为两快，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大。因此在真正需要垃圾回收的时刻，复制算法的效率是很高的。又由于对象在垃圾回收过程中统一被复制到新的内存空间中，因此，可确保回收后的内存空间是没有碎片的。该算法的缺点是始终有一部分内存空间未利用。Sun Hotspot JVM 的新生代串行垃圾回收器中使用了复制算法的思想。新生代分为 eden 空间、from 空间、to 空间 3 个部分。其中 from 空间和 to 空间可以视为用于复制的两块大小相同、地位相等，且可进行角色互换的空间块。from 和 to 空间也称为 survivor 空间，即幸存者空间，用于存放未被回收的对象。在垃圾回收时，eden 空间中的存活对象会被复制到未使用的 survivor 空间中 (假设是 to)，正在使用的 survivor 空间 (假设是 from) 中的年轻对象也会被复制到 to 空间中 (大对象，或者老年对象会直接进入老年带，如果 to 空间已满，则对象也会直接进入老年代)。此时，eden 空间和 from 空间中的剩余对象就是垃圾对象，可以直接清空，to 空间则存放此次回收后的存活对象。这种改进了的复制算法既保证了空间的连续性，又避免了大量的内存空间浪费。

• 标记压缩算法(Mark-Compact)

  复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在年轻代经常发生，但是在老年代更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活的对象较多，复制的成本也将很高。标记-压缩算法是一种老年代的回收算法，它在标记-清除算法的基础上做了一些优化。也首先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。

• 增量算法 (Incremental Collecting)

  通常在垃圾回收过程中，应用程序线程会处于挂起状态（stop the world）暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。增量算法的基本思想是，如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

• 分代收集算法 (Generational Collecting)

  分代收集算法是基于对象的生命周期不同和各种垃圾收集算法的优点综合起来的一个收集算法；它将内存空间划分为不同的几块，用来存放不同生命周期的对象，针对不同的内存区域采用对应的合适收集算法来收集垃圾对象。以 Sun Hot Spot 虚拟机为例，它将所有的新建对象都放入称为年轻代的内存区域，年轻代的特点是对象会很快回收，因此，在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老生代的内存空间。在老生代中，几乎所有的对象都是经过几次垃圾回收后依然得以幸存的。因此，可以认为这些对象在一段时期内，甚至在应用程序的整个生命周期中，将是常驻内存的。如果依然使用复制算法回收老生代，将需要复制大量对象。再加上老生代的回收性价比也要低于新生代，因此这种做法也是不可取的。根据分代的思想，可以对老年代的回收使用与新生代不同的标记-压缩算法，以提高垃圾回收效率。

Sun Jvm 垃圾收集器简介

• 垃圾收集器搭配图
  

• serial GC

  serial GC 是一个单线程的，采用复制收集算法的垃圾收集器，在工作的时候会导致应用程序停顿。

• ParNew GC

  ParNew Gc 是一个多线程的，采用复制收集算法的垃圾收集器，在工作的时候会导致应用程序停顿。它和 Parallel Scavenge GC 不同的时它可以喝CMS收集器搭配工作。

• Parallel Scavenge

Parallel Scavenge是一个多线程的，采用复制收集算法的垃圾收集器，在工作的时候会导致应用程序停顿。    

• serial Old GC

  serial Old GC 是一个单线程的，采用标记清除整理算法的垃圾收集器，在工作的时候会导致应用程序停顿。

• CMS GC

  CMS GC 是一个并发，低停顿的垃圾回收器，在工作的大部分时间中，应用线程可以和垃圾回收线程并发运行，不会一直导致应用程序处于停顿状态。

• Parallel Old

  Parallel Old GC 是一个多线程，采用标记压缩算法的垃圾回收器，在工作的时候会导致应用程序停顿。

  GC 相关参数总结

• 与串行回收器相关的参数

  -XX:+UseSerialGC:在新生代和老年代使用串行回收器。

  -XX:+SuivivorRatio:设置 eden 区大小和 survivor 区大小的比例。

  -XX:+PretenureSizeThreshold:设置大对象直接进入老年代的阈值。当对象的大小超过这个值时，将直 接在老年代分配。

  -XX:MaxTenuringThreshold:设置对象进入老年代的年龄的最大值。每一次 Minor GC 后，对象年龄 就加 1。任何大于这个年龄的对象，一定会进入老年代。

• 与并行 GC 相关的参数

  -XX:+UseParNewGC: 在新生代使用并行收集器。

  -XX:+UseParallelOldGC: 老年代使用并行回收收集器。

  -XX:ParallelGCThreads：设置用于垃圾回收的线程数。通常情况下可以和 CPU 数量相等。但在 CPU 数量比较多的情况下，设置相对较小的数值也是合理的。

  -XX:MaxGCPauseMills：设置最大垃圾收集停顿时间。它的值是一个大于 0 的整数。收集器在工作时， 会调整 Java 堆大小或者其他一些参数，尽可能地把停顿时间控制在 MaxGCPauseMills 以内。

  -XX:GCTimeRatio:设置吞吐量大小，它的值是一个 0-100 之间的整数。假设 GCTimeRatio 的值为 n，那么系统将花费不超过 1/(1+n) 的时间用于垃圾收集。

  -XX:+UseAdaptiveSizePolicy:打开自适应 GC 策略。在这种模式下，新生代的大小，eden 和 survivor 的比例、晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小、吞吐量和停顿时间之间 的平衡点。

• 与 CMS 回收器相关的参数

  -XX:+UseConcMarkSweepGC: 新生代使用并行收集器，老年代使用 CMS+串行收集器。

  -XX:+ParallelCMSThreads: 设定 CMS 的线程数量。

  -XX:+CMSInitiatingOccupancyFraction:设置 CMS 收集器在老年代空间被使用多少后触发，默认为 68%。

  -XX:+UseFullGCsBeforeCompaction:设定进行多少次 CMS 垃圾回收后，进行一次内存压缩。

  -XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收。

  -XX:+CMSParallelRemarkEndable:启用并行重标记。

  -XX:CMSInitatingPermOccupancyFraction:当永久区占用率达到这一百分比后，启动 CMS 回收 (前提是-XX:+CMSClassUnloadingEnabled 激活了)。

  -XX:UseCMSInitatingOccupancyOnly:表示只在到达阈值的时候，才进行 CMS 回收。

  -XX:+CMSIncrementalMode:使用增量模式，比较适合单 CPU。

• 与 G1 回收器相关的参数

  -XX:+UseG1GC：使用 G1 回收器。

  -XX:+UnlockExperimentalVMOptions:允许使用实验性参数。

  -XX:+MaxGCPauseMills:设置最大垃圾收集停顿时间。

  -XX:+GCPauseIntervalMills:设置停顿间隔时间。

• 其他参数

  -XX:+DisableExplicitGC: 禁用显示 GC。

Jekyll 快速入门

1. 3分钟-github搭建个人主页

1. 创建一个新的仓库

   访问 https://github.com 并创建一个名为： USERNAME.github.com 的仓库

2. 安装Jekyll-Bootstrap

   选择你想存放博客文件的文件夹，在终端中输入如下命令：

   git clone https://github.com/plusjade/jekyll-bootstrap.git USERNAME.github.com
   
   cd USERNAME.github.com git
   
   git remote set-url origin     git@github.com:USERNAME/USERNAME.github.com.git 
   
   git push origin master
   

3. 益处

   在github花费几分钟对你的blog进行魔法处理后，你就可以在公网通过地址：http://USERNAME.github.com
   访问你的blogle，很神奇对吧！

   Already have your blog on GitHub?

   我假设你已经在你的机器上安装了Jekyll。在本地启动 Jekyll-Bootstrap ：

   $ git clone https://github.com/plusjade/jekyll-bootstrap.git
   $ cd jekyll-bootstrap
   $ jekyll serve
   

   访问地址：http://localhost:4000.就可以看到结果

2. 本机运行Jekyll

为了在本机预览你的blog,你需要安装 Jekyll ruby gem。 需要注意 gem 的依赖会同时安装。

$ gem install jekyll

如果在启动的过程中出现问题，可以参考 Jekyll 安装文档. 你也可以Jekyll的github主页提问题。

$ cd USERNAME.github.com 
$ jekyll serve

通过地址：http://localhost:4000/ 访问你的blog。

3. 创建一个发布

通过rake task创建发布非常容易：

$ rake post title="Hello World"

rake task 使用合适的格式化文件名称和YAML 文件头格式创建新文件. 确保要使用你自定义的title. 默认文件的名的时间是当前日期。

4.创建页面

通过rake task创建页面非常容易:

$ rake page name="about.md"

Create a nested page:

$ rake page name="pages/about.md"

Create a page with a “pretty” path:

$ rake page name="pages/about"
# this will create the file: ./pages/about/index.html

The rake task automatically creates a page file with properly formatted filename and YAML Front Matter as well as includes the Jekyll Bootstrap “setup” file.

5.发布

当你完成要发布博文的编写和相关文件的修改，使用下面的命令提交到远程github仓库：

$ git add .
$ git commit -m "Add new content"
$ git push origin master

远程提交完成后，github会自动帮你构建站点文件.

6.定制化

Jekyll-Bootstrap 可以作为一个blog的基础平台。我们有多种方式对其按自己的意图进行深度定制。 下面几种技术可以用对其进行深度定制:

主题

Jekyll-Bootstrap 支持模块化主题。 主题之间可以共存并根据需要启用或停用。

blog 配置

Jekyll and Jekyll-Bootstrap 拥有一个简单且强大的 Jekyll 配置系统。 你可以:

Specify a custom permalink format for blog posts.
Specify a commenting engine like disqus, intensedebate, livefyre, or custom.
Specify an analytics engine like google, getclicky, or custom.

编程接口

API文档页面记录了在Jekyll 和 Jekyll-Bootstrap中可以使用的主要数据结构和变量。通过阅读这些文档你可以知道如何使用，在哪里使用Jekyll提供的这些数据和代码

Jekyll 介绍

高度推荐

如果你计划定制自己的blog，我高度推荐你阅读Jekyll 介绍文档。 文档介绍了Jekyll的核心工作原理。