发表于   |   分类于   |  

前言

Java web应用使用部署描述文件来绝对URL映射到Servlets的规则,哪些URL需要验证，以及一些其他的信息，这个文件就是web.xml，在servlet标准中这个文件位于应用war包的WEB-INF/目录下。
更多web.xml标准的信息，可以访问: the Metawerx web.xml reference wiki和 the Metawerx web.xml reference wiki

About Deployment Descriptors

web应用部署描述文件可以反映class文件,资源，配置，以及Java web server 使用它们来应对web请求。当web应用接收到请求时，通过应用部署描述文件把url映射到处理请求的代码上。
部署描述文件是一个名为web.xml的文件，它存在于war包下面的WEB-INF/目录下，是一个以<web-app>为根的XML文件。
以下是一个简单的web.xml示例，其将所有的URL路径映射到mysite.server.ComingSoonServlet:

阅读全文 »

发表于   |   分类于   |  

引入

1
2
3
4
5
6
[root@localhost sync]# free -m
             total       used       free     shared    buffers     cached
Mem:         32094      29292       2802          0        274       1647
-/+ buffers/cache:      27370       4724
Swap:            0          0          0
<!-- more -->

这是一台Java同步服务器的内存占用情况，使用jmap查看堆上信息:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@localhost sync]# jmap -histo 7840

 num     #instances         #bytes  class name
----------------------------------------------
   1:      77399077     5156382528  [C
   2:      41662587     3924901448  [I
   3:      33678441     2424847752  java.util.LinkedHashMap$Entry
   4:      64361432     2059565824  java.lang.String
   5:      18967113     1669105944  java.util.regex.Matcher
   6:       9996594     1534988024  [Ljava.lang.Object;
   7:       7225435     1235477264  [Ljava.util.HashMap$Entry;
   8:      11458421     1074750168  [B
            ·
            ·
            ·
Total     332044853    22585874416

上面这个输出中有好几个问题，暂时先不管。
看下Java的配置：Xms26g -Xmx26g -Xmn12g -XX:PermSize=1024M -Xss2M
实际占用的29G内存中Java heap占了22G，
再看下PS的结果：ps -aux|sort -k 1 -r |less

1
2
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         7840 22.3     82.5  45956536 27124588 ?   Sl   May19 380:04 java

可以看到Java 进程占了27G。
一般来说同步程序并需要这么多的内存，查看GC情况:

1
2
3
[root@localhost sync]# jstat  -gc 7840
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT   
 0.0   65536.0  0.0   65536.0 13148160.0 9207808.0 14049280.0 10819203.6 1048576.0 18093.7    125   25.202   0      0.000   25.202

问题1:

OLD区已经快满了(10/14),
回顾下对象是如何进入old区的：

  • 长期存活的对象将进入老年代，对象在Eden区中经过第一次MinorGC之后进入Survivor区中，每经过一次minorgc如果没有被回收，默认经过15次gc还未被回收就会进入old区
  • 大对象直接进入老年代，虚拟机提供了一个-XX:PretenureSize参数,大于这个值的对象直接在老年代中分配。避免了再Eden区和Survivor区中发生大量的内存复制（该参数只对几个收集器起作用）。
    JVM内存回收过程

    1、对象在Eden区完成内存分配
    2、当Eden区满了，再创建对象，会因为申请不到空间，触发minorGC，进行young(eden+1survivor)区的垃圾回收
    3、minorGC时，Eden不能被回收的对象被放入到空的survivor（Eden肯定会被清空），另一个survivor里不能被GC回收的对象也会被放入这个survivor，始终保证一个survivor是空的
    4、当做第3步的时候，如果发现survivor满了，则这些对象被copy到old区，或者survivor并没有满，但是有些对象已经足够Old，也被放入Old区 XX:MaxTenuringThreshold
    5、当Old区被放满的之后，进行fullGC

问题2

heap中char数组占用内存过多，但是程序并有显示生成char对象。
Why my Java heap is with so many char

811k of char[] correspond to 800k of Strings, so yes, you have too many Strings.
If you’re having a memory leak (judging by the tag), then it’s most probably are strings in a HashMap. You have 800k instances of strings, 200k instances of hash entries, 30k of maps. This probably means that your strings are kept in this cache and are not removed. Global map is a frequent cause of memory leaks, one needs to make sure that they are evicted from this cache.

Since all these values are not being GC-ed, you could try analyzing an object graph to see what’s holding them with a tool like JProfiler.

Why does the profiler show large numbers of char[] instances when I am not creating any?

Take a look at the String source code. The String object itself contains a cached hash code, a count of the number of characters (again, for optimisation purposes), an offset (since a String.substr()points to the original string data) and the character array, which contains the actual string data. Hence your metrics showing that String consumes relatively little, but the majority of memory is taken by the underlying character arrays.

String is the perfect example. It contains a handful of primitive fields, plus the char[]. The char[]accounts for the vast majority of the memory usage. The shallow size of String is very small, but it’s retained size is much larger, since that includes the char[].
大概就是说尽管没有直接使用char数组，但是对String的频繁使用也会造成这个问题。

参考链接:

Java内存与垃圾回收调优

发表于   |   分类于   |  

之前因为项目需要先从redis中取出key的列表，再循环这些列表操作后写入到redis中，因为使用pipline，中间出现了一些问题记录学习下。
最初の源代码:

阅读全文 »

发表于   |   分类于   |  

原文地址:http://tutorials.jenkov.com/java-servlets/gzip-servlet-filter.html

简介

A GZip Servlet Filter can be used to GZip compress content sent to a browser from a Java web application. This text will explain how that works, and contains a GZip Servlet Filter you can use in your own Java web applications. If you do not know what a Servlet filter is, read my text on Servlet Filters.

gzip servlet filter 可用来压缩网页内容。本文将介绍其如何工作，以及如何使用gzip servlet filter 在你的web服务器中。如果不了解servlet filter是什么可以参考这篇文章:Servlet Filters.

为什么要使用gzip压缩网页内容

GZip compressing HTML, JavaScript, CSS etc. makes the data sent to the browser smaller. This speeds up the download. This is especially beneficial for mobile phones where internet bandwidth may be limited. GZip compressing content adds a CPU overhead on the server and browser, but it is still speeding up the total page load compared to not GZip compressing.

gzip 压缩html、Javascript，css等等文件，目的是为了是发送到浏览器的数据更小，加速下载，这对于限制了带宽的移动端作用特别大。当然gzip增加了server端和浏览器端的cpu的压力，但是总体来说还是加速了页面的载入。

阅读全文 »

发表于   |   分类于   |  

前言

本文为实验楼Spring框架入门教程 学习笔记

Spring中的相互引用

  • 引用不同配置文件中的Bean，可以使用ref标签，结合bean属性
  • 引用相同配置文件中的Bean，可以使用ref标签,结合local属性

ref 标签中 bean 属性，既可以引用相同xml文件中的bean，也可以引用不同xml文件中的bean，但是，考虑到项目的可读性，引用相同xml配置文件的bean时，应该尽量使用 local 属性。

阅读全文 »

发表于   |   分类于   |  

语言特性

  • Ruby是解释执行的。
  • 除了NIL和false 之外其他值都表示true

鸭子类型

  • Ruby在大部分时间里都表现的像一门强类型语言。Ruby是在运行时而非编译时进行类型检查（动态类型）。
  • 所谓鸭子类型并不关心其内在类型是什么。只要看上去像就可以了。
    阅读全文 »

发表于   |   分类于   |  

简介

  • jps JVM process status 显示系统内所有的hotspot虚拟机进程。
  • jstat JVM statistics monitoring tool 收集hotspot虚拟机各方面的运行数据
  • jinfo configuration info for java 显示虚拟机配置信息
  • jmap 生成虚拟机的内存转储快照
  • jhat JVM heap dump browser 用于分析heapdump文件。
  • jstack stack trace for java 显示虚拟机上的线程快照
    阅读全文 »

发表于   |   分类于   |  

pipline模式

Pipeline：“管道”，和很多设计模式中的“管道”具有同样的概念，pipleline的操作，将明确client与server端的交互，都是“单向的”：你可以将多个command，依次发给server，但在此期间，你将无法获得单个command的响应数据，此后你可以关闭“请求”，然后依次获取每个command的响应结果。
从简单来说，在IO操作层面，对于client而言，就是一次批量的连续的“write”请求，然后是批量的连续的“read”操作。其实对于底层Socket-IO而言，对于client而言，只不过是多次write，然后一次read的操作；对于server端，input通道上read到数据之后，就会立即被实施，也会和非pipeline一样在output通道上输出执行的结果，只不过此时数据会被阻塞在网络缓冲区上，直到client端开始read或者关闭链接。神秘的面纱已被解开，或许你也能创造一个pipeline的实现。
非pipleline模式：
Request——>执行
——>Response
Request——>执行
——>Response
Pipeline模式下：
Request——>执行，Server将响应结果队列化
Request——>执行，Server将响应结果队列化
——>Response
——>Response
Client端根据Redis的数据协议，将响应结果进行解析，并将结果做类似于“队列化”的操作。

阅读全文 »

发表于   |   分类于   |  

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1
$ hexo new "My New Post"

More info: Writing

Run server

1
$ hexo server

More info: Server

Generate static files

1
$ hexo generate

More info: Generating

Deploy to remote sites

1
$ hexo deploy

More info: Deployment