JVM参数调整无非是调整堆中各种内存的大小，选择最优的GC算法（行为）。一般有两个指标来考量： Pause时间 Throughput GC类型有： Serial GC The serial collector uses a single thread to perform all garbage collection work, which makes it relatively efficient since there is no communication overhead between threads. It is best-suited to single processor machines, since it cannot take advantage of multiprocessor hardware, although it can be useful on multiprocessors for applications with small data sets (up to approximately 100MB). The serial collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseSerialGC The Throughput Collector -XX:+UseParallelGC主要是针对young generation的，Tenured Generation还是Serial Collector The parallel collector (also known as the throughput collector) performs minor collections in parallel, which can significantly reduce garbage collection overhead. It is intended for applications with medium- to large-sized data sets that are run on multiprocessor or multi-threaded hardware. The parallel collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseParallelGC. New: parallel compaction is a feature introduced in J2SE 5.0 update 6 and enhanced in Java SE 6 that allows the parallel collector to perform major collections in parallel. Without parallel compaction, major collections are performed using a single thread, which can significantly limit scalability. Parallel compaction is enabled by adding the option -XX:+UseParallelOldGC to the command line The Concurrent Low Pause Collector -Xincgc or -XX:+UseConcMarkSweepGC 主要是正对Tenure Generation的 The concurrent collector performs most of its work concurrently (i.e., while the application is still running) to keep garbage collection pauses short. It is designed for applications with medium- to large-sized data sets for which response time is more important than overall throughput, since the techniques used to minimize pauses can reduce application performance. The concurrent collector is enabled with the option -XX:+UseConcMarkSweepGC. The Incremental Low Pause Collector -XX:+UseTrainGC 下面介绍一下各种参数的意义 -Xms -Xmx Heap 内存设置 堆内存不是一下子就分配-Xmx大小的，随着GC的进行，从-Xms慢慢递增的 基本来说Heap内存分配太大的话，GC的次数会减少，但是做一次GC的Pause时间会很大。反之亦然。 + -Xincgc Incremental GC,也即GC的Train算法, 增量GC一次只收集部分Heap对象，而不是针对整个堆。如果GC Pause 时间太长的话可以考虑用这个选项调试一下 -Xss 栈大小设置，从Java6开始，32-bit JVM默认是320k，64-bit JVM默认是1024k。（题外话，64-bit JVM并不会所有类型double一下，只是可分配的Heap内存和线程数会更多） 注意栈大小设置太小的话，递归多的话会出现栈溢出；栈太大的话，如果Application中线程比较多（每个线程有自己的栈），可分配的栈变少，就会出现 running out of memeory问题。 Server 和 Client端GC策略不同，考虑到可用的Heap Size,CPU数量等。
按代的垃圾收集机制, 主要分为三种： 复制算法，空间被分为等大的两块，从根开始访问每一个关联的活跃对象，将空间 A 的活跃对象全部复制到空间 B，然后一次性回收整个空间 A，优点：只访问活跃对象，将所有活动对象复制走之后就清空整个空间，不用去访问死对象，所以遍历空间的成本较小，缺点：需要巨大的复制成本和较多的内存； 标记清除算法，从根开始访问所有活跃对象，标记为活跃对象。然后再遍历一次整个内存区域，把所有没有标记活跃的对象进行回收处理，优点：不需要额外的空间，缺点：较长的 GC 暂停时间，较大的扫描时间开销，产生较多的空间碎片； 标记清除整理算法，综合上两种算法的优点，先标记活跃对象，然后将其合并成较大的内存块。 代的划分： 年轻代：新创建的对象分配在此，研究表明，大部分程序所产生的对象都在此消亡，几乎所有的收集器为年轻代使用复制算法，年轻代又被划分为 1个伊甸园区(Eden)和 2个存活区(Survivor)用来实施复制算法； 也称Minor Collection，基于大多数对象Die Young的原则 年老代(Tenured)：从年轻代存活下来的对象被复制到年老代，主要实施标记清除或标记清除整理算法；也称Major Collection， Full GC. 该过程会比较慢因为会遍历所有的Live 对象。 持久代(Permanent)：装载的类数据和方法存储于此，无可消亡对象。 基于JVM层的性能调优思路大概是： 对程序进行profiling, 主要考虑方法调用过程，花费的时间等 dump出heap或者实时监控分析 对象大小，引用关系 启动Java程序时打开 -verbose:gc, 分析GC执行情况，执行前后Heap中对象在图上显示有什么pattern（如果有图形显示的工具的话） 根据分析结果检查线程，死锁，内存泄漏的蛛丝马迹。最后可以考虑对JVM启动参数进行调整，这个会改变GC的算法及内存（heap）分配情况 单处理器时基本是基于Generation的Copy算法或者Mark-Sweep-Compact算法；多处理器时考虑并行GC因此可以指定更多的GC策略，一个处理器做GC，另一个继续运行Applicaiton。这样不用象单处理器一样GC时Applicaiton Pause住。
关系数据库 基于严格的关系数据库理论，但面对现有电子商务，SNS网站业务的挑战，Scalability和Performance不能很好地解决 Key-Value数据库 No SQL数据库如google的Big Table. 解决了关系数据库的不足，但基于Key取值，并不能如同SQL一般进行查询。因为数据都是非结构化，离散的。 面向文档的数据库 如：MongoDB，支持查询 图形数据库 据说已有厂家产品支持节点和边的图形数据库
通过下面的调用链 PUMA接口 Portal,portlets PUMA (Portal User Management Architecture) WMM (Websphere Member Manager) 最终WMM.xml中会配置LDAP连接的信息，从而关联portal server和LDAP server
加入WS-Security Policy？ 在Web Service 前加入网关安全过滤？ 在soap header 中加入user id/caller id, org id/name 的信息。当然别人也可以仿造
SOP(Same Orgin Policy)限制 这个主要通过 JSONP(padding)解决，当然server proxy, iframe也是可选的方案 file upload IFrame是一种方案，其他可选的有Applet, Flash 插件方案。 Backward/Forward/收藏夹 不是很清楚解决方案，记得曾看到过有通过同一个页面加锚点的方案，不是很理解。
堆栈参数调整(基于 Sun Hotspot ) -Xss:设置任何线程的本地方法栈大小 -Xms:设置JVM初始堆大小 -Xmx:设置JVM最大堆大小 -XX:PermSize=:设置JVM Perm generation的初始大小 -XX:MaxPermSize=:设置JVM Perm Generation的最大大小 注意：所有以-X开头的JVM参数都不是标准参数（未包含在JVM规范中），即可能不会被所有版本的JVM实现；以-XX开头的JVM参数可能指定了特定的系统平台，且可能在没有通知的情况下更改，因此不推荐使用。 通过jdk5 自带的JConsole查看是否有memory leak 先以下面的方式启动需要调优的目标程序JVM cd C:\Program Files\Java\jdk1.6.0_21\demo\jfc\SwingSet2 java -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=localhost -jar SwingSet2.jar 打开JConsole(JDK5)/JVisualVM(JDK6)以本地进程方式连接目标进程.查看memory, classes, thread,CPU情况。 注意在我Vista机器上 必须加上 -Djava.rmi.server.hostname=localhost 才能连接，否则报“连接失败，是否重试”的错误。 查看heap中的主要对象，用jmap 可以查看histogram 查看对象的reachable jhat
最近在拜读Martin Fowler的Enterprise Integration Pattern，对于基于消息系统的应用集成了解了不少。虽然以前的工作也涉及IBM MQ但体会总是不是很深。在不同应用，分布式环境中的集成中，消息中间件在可靠性方面是优势。 这跟我的第一印象是刚好相反的，以前总以为消息总会如同发出的信件一下，也许会石沉大海吧？哪有同步方式，比如打电话，可靠？仔细一想，其实不然。同步方式在分布式应用中依赖太多，通讯双方同时在线，网络可靠，load安全（不要被太多的Request压死了）等。 这些方面消息中间件却是优势。同时消息中间件解耦了消息生产者和消费者。发送消息和接收消息的系统只要跟消息中间件打交道。 记得以前有个项目中自己实现了个消息系统，J2SE中多个应用之间通过消息通讯。主要是通过RMI和Observer模式实现。回想起来也算是分布式消息系统吧？不同的是发送方和接受方是耦合的。比如发送方（subject）维护了一个接受方的listener list(RMI 回调接口），发送消息时轮询list并RMI回调接口。 再回想起以前被面的时候，一个经理跟我谈到SOA时，不停的challenge我项目中SOA框架有啥好处。他的意思是他现在项目中用JSP，Servlet分层用的很好啊。然后我就从loosely coupling, reuse等角度来讲这个问题。SOA框架给我们解耦了Service的集成（通过ESB )。如同Spring封装了对象的创建和维护消除我们在自己程序中通过Factory，Singleton来创建对象，框架帮我们做了这部分工作。
Collection of handy online tools for developers, with great UX.
The "REST With Spring" Course:
A one-of-a-kind resume builder that keeps your privacy in mind. Completely secure, customizable, portable, open-source and free forever. Try it out today!
just for study, from internet.
A minimal Jekyll Theme to host your resume (CV) on GitHub with a few clicks.