有美女拍，心情还是不好．
片子已经完全受了情绪的影响了．
但更多MM在明天，
待续．．．

    2. 客户服务。从CIO到高级架构师都应该能够坐在客服的位置上并且接听客服热线，这样一来你不仅可以分享电话那端客户的喜悦，而且有机会给他们讲解使用的方法从而避免以后出现严重的问题。

   3. 公众演讲。你应该在同僚面前做至少一次公开的演讲，哪怕是介绍即时通讯系统如何工作的五分钟演示，这样一来，你可以逐渐掌握在众人面前如何沉着稳定的解释一件事情的能力。如果你比较紧张，那么你可以请一个助手或者采用圆桌会议的形式，一旦你陷入了僵局，总有人会站出来帮你释放压力。

    4. 给别人讲课。最好的学习方式是教导他人。

    5. 多听少说。我很少谈论自己不知道的事情，我更愿意倾听其他人讨论一些事情和想法，“哦，真希望我早点知道这个”。

    6. 网络常识。无论你是否是网络工程师、客服人员、业务分析员或者系统管理员，你都应该明白网络的基本原理并且能够解决一些基础的故障，你应该了解域名解析并且知道如何检查，包括使用ping命令以及跟踪路由信息。

    7. 系统管理，比如文件权限、访问控制以及电脑怎样和域控制器交互。你不必成为专业的系统管理员，但是多了解一些系统方面的知识可以减少很多令人头疼的麻烦。

   8. 网络捕捉。每一个IT从业人员都应该会使用wireshark、netmon、snoop或者其他一些基本的网络捕捉工具。你不需要了解一切，但是应该能够捕捉网络异常并且提交给专业的网络工程师审查。

    9. 延迟和带宽。延迟是指收发数据包所需要的时间，而带宽是指一次连接所能够携带的数据量。他们之间有关联，但是并不形成简单的比例关系。一个高带宽利用率的连接可能会导致延迟增加；但是如果连接没有过载，增加带宽并不会减少延迟。

    10. 使用脚本。每个IT人士都应该能够写出一个脚本来迅速完成工作。这并不意味每个人都需要成为程序员，你不需要象程序员那样——输入一个错误的信息，然后观察异常并且记录下来，但是你应该能够使用脚本一次完成一些简单的事情，比如，删除数据、发送邮件以及拷贝文档。

    11. 制作备份。在你做任何操作之前，为了自己的便利，一定要先做备份。

    12. 检查备份。如果你没有仔细检查之前所做的备份，那么你并不知道它是否真的可用。相信我。

    13. 写作文档。他人没有办法清楚的知道你曾经做了什么以及为什么要那么做，即使是你认为简单的操作或者有充分的理由，请完整的记录你做过的事情，并且放置在每一个人都能够找到的地方。

    14. 读《the Cuckoo's Egg》。我并不认识作者Cliff Stoll也不是在推销，而是因为这可能是最好的一本不仅仅介绍技术手段的安全方面的著作。

    15. 在项目团队中通宵加班。没有人喜欢加班，但是这的确是IT工作的一部分。当你和团队成员一起熬夜完成了一个非常困难的项目，你所获得的信任和友谊是无可替代的。

   16. 规范布线。看起来容易，做起来很有学问。也许你认为部署一台新的服务器只需要五分钟——只要连上所有的接口即可。千万不要这样做，一定要按照正确的方式，给所有的线缆贴上标签（是的，所有的），并且把它们捆扎干净整齐。这样一来，一旦出现故障，你能够迅速发现问题所在，节省大量的时间。

    17. 能源规则。你应该知道一些电源规范，比如一个耗电3.5KW的设备需要一吨的空气冷却，在这里一吨的意思不是很多，而是准确的数字。（注：3.5KW大概是一台1U或者2U的服务器的功率；一吨的冷气需要三个10英寸的冷却风扇来处理；30吨冷气需要80个20英寸的风扇，30吨冷气是相当可观的。）

    18. 项目管理。如果你管理过至少一个项目，那么当下次项目经理向你询问进度的时候，你就明白为什么需要这些数据。更理想的情况是你已经把那些项目管理需要的统计数据提交给了项目经理。

   19. 了解项目的经营成本和资金成本。经营成本是指运行所需要的开支，资金成本是指在一段时间内（比如36个月）增加能够发挥效益的设备和人员。经营成本有时候会带来收益，有候会成为负担，分清楚其中的区别，能够帮助你做出决定。

    20. 理解业务流程。如果能够使现有的业务流程得到改善，那么就可以让好的技术赢得更多的机会。不需要使用非常复杂的工具，你只需要询问几个简单的问题并且利用已知的业务常识就可以做到这一点。

    21. 据理力争。不要害怕和别人争论那些你认为有错误的结论，但是同时你必须知道什么时候应该停止，这将导致你是否会收获一个好的创意或者是是被人暴打一顿。

    22. 解决问题。如果你需要向领导汇报已经出现的问题，那么你最好至少有一个解决方案。

    23. 如果你有比较初级的问题，那么确定只问一次，然后把答案记录下来，以免忘记。如果你问同一个人同样的问题超过两次，你会被当作他们眼中的白痴。

   24. 依靠自己。如果你通过自己的努力把一个问题搞清楚需要两倍于向其他人请教的时间，那么最好还是依靠自己的努力来解决，这样你可以印象更加深刻。如果仅仅凭借自己的力量需要更多的时间，那么不耻下问。

    25. 避免在谈话中使用缩略语。

    26. IT经理：倾听下属的谈话。倾听下属的谈话，因为他们比你知道的更多。如果你认为他们知道的太少，解雇他们并且雇佣更聪明的人；如果你认为自己是最聪明的，那么你最好辞职。

    27. IT经理：如果你知道答案，那么不要仅仅给出答案，而应该向他人提出恰当的问题并让他们自己得到解决方案。当你清楚的知道每个人都在期待你尽快解决问题的时候，并且你恰好知道如何使系统迅速恢复正常的时候，采用诱导的管理方法显然是非常困难的；但是从长远来看，你将会得到来自下属的回报，毕竟，你不可能每次都恰好知道问题的答案。

   28. IT经理：如果有人第一次做错了事情，这不是犯错误，而是学习所需要代价。如果重复犯同样的错误，让他们回家去吧。记住：每一天都是你的下属学习的机会，确保他们学到一些有价值的东西，而不仅仅是发现别处有更好的工作。

    29. IT经理：总是给你的下属比他们所能够完成的稍微多一些的工作。尽管他们会抱怨你不近人情，但是每个员工都需要抱怨点什么，所以工作繁重成为一个很好的理由。进一步说，如果你的员工在下午两点钟的时候就完成了当天的工作，他们会认为没有什么可以做的了只是不能走消磨时间而已。繁重的工作任务将使得你的员工不会出现这样的困惑。

    30. IT经理：扬长避短。如果有人在一个团队中工作良好，但当他带领自己的团队的时候却差强人意，那么最好让他更多的在团队里工作。
本文转载自『左岸读书_blog!』

并不是因为最近没有什么可写的，
想写一些东西，
比如看了一部很好看的电影，
《追风筝的人》。
想写一些东西，
比如这个月做火车的做到吐，
从内蒙到沈阳，从沈阳到北京，从北京到沈阳，从沈阳到北京，从北京到沈阳，终于昨天又回到了北京。
想写一些东西，
比如新的工作地点，新的宿舍环境。
位于著名的商业街--西单
想写一些东西，
比如住的地方在儿童医院那里，
在饭店吃饭时总能碰到一些患病的孩子们。
想写一些东西，
比如对地震中发生的事
自己对此的态度。
想写一些东西，
比如参加了同事的婚礼，
他和女友相处十年终于成眷属。
想写一些东西，
比如去买衣服，一件T恤，前面写着艺术体的汉字：“东西”
拿起一看，后背写着：“不是”。

这一年，国家经历太多的不幸。
天灾，人祸。
虽然国家内部是有太多的瑕疵。
但只要我们在事件之余，
不再是谈论捐钱的数目，
不再是争论是不是愤青，
不再是议论是不是有人在发国难财。
而是经营好各自的心灵家园。
那么明天，
将会看到一个幸福的中国。

加油，中国。
中国，加油。

A2 我家大门常打开 开放怀抱等你——那英
拥抱过就有了默契 你会爱上这里——孙燕姿

B1 不管远近都是客人请不用客气——孙悦
相约好了在一起 我们欢迎你——王力宏

A3 我家种着万年青 开放每段传奇——韩红
为传统的土壤播种 为你留下回忆——周华健

B2 陌生熟悉都是客人请不用拘礼——梁咏琪
第几次来没关系 有太多话题——羽泉

C1 北京欢迎你 为你开天辟地——成龙
流动中的魅力充满着朝气——任贤齐
北京欢迎你 在太阳下分享呼吸——蔡依林
在黄土地刷新成绩——孙楠

Solo

A4 我家大门常打开 开怀容纳天地——周笔畅
岁月绽放青春笑容 迎接这个日期——韦唯

B3 天大地大都是朋友请不用客气——黄晓明
画意诗情带笑意 只为等待你——韩庚

C2 北京欢迎你 像音乐感动你——汪峰
让我们都加油去超越自己——莫文蔚
北京欢迎你 有梦想谁都了不起——谭晶
有勇气就会有奇迹——陈奕迅

C3 北京欢迎你 为你开天辟地——阎维文
流动中的魅力充满着朝气——戴玉强
北京欢迎你 在太阳下分享呼吸——王霞 李双松
在黄土地刷新成绩——廖昌永

C4 北京欢迎你 像音乐感动你——林依轮
让我们都加油去超越自己——张娜拉
北京欢迎你 有梦想谁都了不起——林俊杰
有勇气就会有奇迹——阿杜

solo 京戏

A5 我家大门常打开 开放怀抱等你——容祖儿
拥抱过就有了默契 你会爱上这里——李宇春

B4 不管远近都是客人请不用客气——黄大炜
相约好了在一起 我们欢迎你——陈坤

C5 北京欢迎你 为你开天辟地——谢霆锋
流动中的魅力充满着朝气——韩磊
北京欢迎你 在太阳下分享呼吸——徐若瑄
在黄土地刷新成绩——费翔

solo

A6 我家大门常打开 开怀容纳天地——汤灿
岁月绽放青春笑容 迎接这个日期——林志玲 张梓琳

B5 天大地大都是朋友请不用客气——张靓颖
画意诗情带笑意 只为等待你——许茹芸 伍思凯

C6 北京欢迎你 像音乐感动你——杨坤 范玮琪
让我们都加油去超越自己——游鸿明 周晓欧
北京欢迎你 有梦想谁都了不起——沙宝亮 满文军
有勇气就会有奇迹——金海心 何润东

C7 北京欢迎你 为你开天辟地——飞儿 庞龙
流动中的魅力充满着朝气——吴克群 齐峰
北京欢迎你 在太阳下分享呼吸——5566 胡彦斌
在黄土地刷新成绩——郑希怡 刀郎

C8 北京欢迎你 像音乐感动你——纪敏加 屠洪刚 吴彤
让我们都加油去超越自己——郭容 刘耕宏 腾格尔
北京欢迎你 有梦想谁都了不起——金莎 苏醒 韦嘉
有勇气就会有奇迹——付丽珊 黄征 房祖明

C9 北京欢迎你 有梦想谁都了不起——全体群唱
有勇气就会有奇迹——全体群唱
北京欢迎你 有梦想谁都了不起——全体群唱
有勇气就会有奇迹——全体群唱

    初中三年级，我有个同学上课看黄色小说，被老师发现，把小说没收了。

    接着，我正好有事要找那老师，到办公室，看那老师正低头工作，怕打扰，就轻手轻脚走到老师旁边。

    老师突然发现我站在他前面，吓一跳，把抽屉砰一声关起来，站起身，又突然坐下去，沉声问我：“你来干什么？”

　　他的脸胀成通红，原来他把抽屉拉开一半，正偷看藏在里面的黄色小说呢！

　　他没多讲，就挥手叫我滚了。

　　只是从此，碰上那老师的课，我就紧张得手心冒汗，不敢看他。每次不幸与他的眼神对上，都感觉他仇恨的目光。

　　那一科，我差点不及格。

　　念研究所的时候，我有个同学跟他未婚妻闹翻了。他一点都没错，只是不知为什么未婚妻突然疏远他。

　　看他实在可怜，我就请你妈妈出面，找那女生谈谈。

　　女生说她未婚夫确实没错，错在把他家里的钥匙交给她。

　　有一天，她帮未婚夫去家拿东西，打开门，赫然发现她未来的公公竟全身光溜溜地坐在沙发上，看色情录像带。

　　她吓得赶快退出来了。只是从此不敢再去面对她未来的公公和婆婆，也不愿再面对我那男同学——她的未婚夫。

　　他们终于分开了，而且因为我和你妈妈，替她保守这个秘密，所以相信一直到今天，那男同学都不清楚出了什么事。

　　你知道我为什么说这两个故事吗？

　　因为你说常看同学们聚成小圈圈讲悄悄话，但是你的耳朵尖，知道他们说什么。

　　于是我问你，你听到他们偷偷说的每个字，对你有什么帮助吗？

　　你要知道，人愈大，愈有隐藏的内心世界。如果你在每个人家装上窃听器，会发现大家背地谈论和正面说的，可能差了十万八千里。

　　人们相忌，竞争愈大，心结常愈深。尤其到你这个年龄，大家开始结党，把臭味相投的朋友聚在一起，去排斥“不相投”的人。你以为知道每个人的隐私，知道每个排斥你的人，也让对方知道“你心里有数”，对自己有好处吗？

　　错了！就像我前面说的故事，只可能更推远彼此的距离。

　　凡事作退一步想，如同在军中，即使大家拿的都是空枪，明明知道里面没有子弹，也不准用枪口对着人。因为不怕一万，只怕万一，过去常有莫名其妙，空枪里出现子弹，打死人的事。

　　孩子，你有没有发现我每次上楼，或经过你的房间，都把脚步放重？

　　因为你的桌子靠窗，你的背对着门，又总是把门打开，我怕你吓到。

　　而且，你长大了，有你自己的世界，可能正偷偷上网，看你要看的东西，我“不想发现”也“不必发现”。所以应该给你时间，把网上的东西跳开来。

　　“未入室，先扬声”，古人早就这么说，意思是在进房间之前，先出一点声音，使屋里的人有心理准备。

　　你很快就会高中毕业，进入大学住校。在宿舍里走动，或进入别人房间之前，是不是都该“扬声”呢？

　　希望你能记住我今天的这番话，在未来给自己，也给别人留点私密的空间，这是每个人都该懂的处世艺术。

    摘自:刘塘<跨一步,就成功>


PS:这两天有位来自天津的朋友访问我的BLOG，难道是你吗？

我不常吸烟，
这一盒还是两个月前买的。
曾经不明白为什么要吸烟，
装酷？或许是吧。
提神？或许是吧。
朋友说吸烟会让人深思。
或许是吧。

想到曾经的目标也不就是现在这样吗。
小富即安，衣食无忧。
我没有抱怨，上帝是公平的。
我不会停下脚步，
我还要继续前行。

这一刻，
我是平静的。
这支烟
它是享受的。

关键字：消息中间件，JMS，点对点，发布/订阅

一、中间件简介

1.1 中间件的定义

　　中间件(middleware)是基础软件的一大类，属于可复用的软件范畴。中间件在操作系统软件，网络和数据库之上，应用软件之下，总的作用是为处于自己上层的应用软件提供运行于开发的环境，帮助用户灵活、高效的开发和集成复杂的应用软件。[1]

　　IDC对中间件的定义为：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件定位于客户机服务器的操作系统之上，管理计算机资源和网络通信。

　　因而中间件是指一类软件，是基于分布式处理的软件，最突出的特点是其网络通信功能。也可认为中间件是位于平台和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，可以有符合接口和协议的多种实现。

1.2 中间件的分类

按照IDC的分类方法，中间件可分为六类：[1]

1) 终端仿真/屏幕转换

2) 数据访问中间件（UDA）

3) 远程过程调用中间件（RPC）

4) 消息中间件（MOM）

5) 交易中间件（TPM）

6) 对象中间件

然而在实际应用中，一般将中间件分为两大类：一类是底层中间件，用于支撑单个应用系统或解决一类问题，包括交易中间件、应用服务器、消息中间件、数据访问中间件等；另一类是高层中间件，更多的用于系统整合，包括企业应用集成中间件、工作流中间件、门户中间件等，他们通常会与多个应用系统打交道，在系统中层次较高，并大多基于前一类的底层中间件运行。

1.2.1 终端仿真/屏幕转换

　　此类中间件用于实现客户机图形用户接口与已有的字符接口方式的服务器应用程序之间的互操作，应用与早期的大型机系统，现在已很少使用。

1.2.2 数据访问中间件

　　此类中间件是为了建立数据应用资源互操作的模式，对异构环境下的数据库或文件系统实现联接。

1.2.3 远程过程调用中间件

　　此类中间件可以使开发人员在需要时调用位于远端服务器上的过程，屏蔽了在调用过程中的通信细节。一个应用程序使用RPC来远程执行一个位于不同地址空间里的过程，在效果上看和执行本地调用相同。

1.2.4 交易中间件

　　此类中间件是专门针对联机交易系统而设计的。联机交易系统需要处理大量并发进程，处理并发涉及到操作系统，文件系统，编程语言，数据通信，数据库系统，系统管理，应用软件等。而交易中间件根据分布式交易处理的标准及参考模型，对资源管理，交易管理和应用进行了实现，从而使得基于交易中间件开发应用程序更为简单。交易中间件基本上只适用于联机交易系统，是一种较为专用的中间件。

1.2.5 消息中间件

　　此类中间件是指利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

　　消息中间件可以即支持同步方式，又支持异步方式。异步中间件比同步中间件具有更强的容错性，在系统故障时可以保证消息的正常传输。异步中间件技术又分为两类：广播方式和发布/订阅方式。由于发布/订阅方式可以指定哪种类型的用户可以接受哪种类型的消息，更加有针对性，事实上已成为异步中间件的非正式标准。目前主流的消息中间件产品有IBM的MQSeries，BEA的MessageQ和Sun的JMS等。

1.2.6 对象中间件

　　传统的对象技术通过封装、继承及多态提供了良好的代码重用功能。但这些对象只存在与一个程序中，外界并不知道它们的存在，也无法访问它们。对象中间件提供了一个标准的构建框架，能使不同厂家的软件通过不同的地址空间，网络和操作系统实现交互访问。对象中间件的目标是为软件用户及开发者提供一种应用级的即插即用的互操作性。目前主流的对象中间件有OMG的CORBA，Microsoft 的COM以及IBM的SOM，Sun的RMI等。

1.3 中间件的特点

　　一般来讲，中间件具有以下一些特点：满足大量应用的需求，运行于多种硬件和操作系统平台，支持分布式计算，支持标准接口和协议。开发人员通过调用中间件提供的大量API，实现异构环境的通信，从而屏蔽异构系统中复杂的操作系统和网络协议。

　　由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。分布式应用软件借助中间件可以在不同的技术之间共享资源。

　　总的来说，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少了程序设计的复杂性，将注意力集中与自己的业务上，不必再为程序在不同软件系统上的移植而重复工作，从而大大减少了技术上的负担。

二、消息中间件原理

　　面向消息的中间件（MOM），提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的MOM通信。MOM提供了有保证的消息发送（至少是在尽可能地做到这一点），应用程序开发人员无需了解远程过程调用（PRC）和网络/通信协议的细节。

2.1 消息中间件简介

　　消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

　　消息中间件适用于需要可靠的数据传送的分布式环境。采用消息中间件机制的系统中，不同的对象之间通过传递消息来激活对方的事件，完成相应的操作。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。消息中间件能在不同平台之间通信，它常被用来屏蔽掉各种平台及协议之间的特性，实现应用程序之间的协同，其优点在于能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻都可以将消息进行传送或者存储转发，这也是它比远程过程调用更进一步的原因。

MOM将消息路由给应用程B，这样消息就可以存在于完全不同的计算机上，MOM 负责处理网络通信。如果网络连接不可用，MOM会存储消息，直到连接变得可用时，再将消息转发给应用程序B。

灵活性的另一方面体现在，当应用程序A发送其消息时，应用程序B甚至可以不处于执行状态。MOM将保留这个消息，直到应用程序B开始执行并试着检索消息为止。这还防止了应用程序A因为等待应用程序B检索消息而出现阻塞。 这种异步通信要求应用程序的设计与现在大多数应用程序不同，不过，对于时间无关或并行处理，它可能是一个极其有用的方法。

2.2 消息中间件与分布式对象调用的比较

　　分布式对象调用，如CORBA，RMI和DCOM，提供了一种通讯机制，透明地在异构的分布式计算环境中传递对象请求，而这些对象可以位于本地或远程机器。它通过在对象与对象之间提供一种统一的接口，使对象之间的调用和数据共享不再关心对象的位置、实现语言及所驻留的操作系统。这个接口就是面向对象的中间件。

　　尽管面向对象的中间件是一种很强大的规范被广泛应用，但是面对大规模的复杂分布式系统，这些技术也显示出了局限性：

1．同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行。

2．客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行，如果由于服务对象崩溃或网络故障导致客户的请求不可达，客户会接收到异常。

　　为了解决这些问题，出现了面向消息的中间件，它较好地解决了以上的问题。

　　消息中间件作为一个中间层软件，它为分布式系统中创建、发送、接收消息提供了一套可靠通用的方法，实现了分布式系统中可靠的、高效的、实时的跨平台数据传输。消息中间件减少了开发跨平台和网络协议软件的复杂性，它屏蔽了不同操作系统和网络协议的具体细节，面对规模和复杂度都越来越高的分布式系统，消息中间件技术显示出了它的优越性：

1．采用异步通信模式：发送消息者可以在发送消息后进行其它的工作，不用等待接收者的回应，而接收者也不必在接到消息后立即对发送者的请求进行处理；

2．客户和服务对象生命周期的松耦合关系：客户进程和服务对象进程不要求都正常运行，如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户不会接收到异常，消息中间件能保证消息不会丢失。
2.3 消息中间件的传递模式

　　消息中间件一般有两种传递模型：点对点模型（PTP）和发布-订阅模型（Pub/Sub）。

1. 点对点模型（PTP）

　　点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发动到由某个名字标识的特定消费者。这个名字实际上对应于消息服务中的一个队列（Queue），在消息传动给消费者之前它被存储在这个队列中。队列可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。

2. 发布-订阅模型（Pub/Sub）

　　发布-订阅模型用称为主题（topic）的内容分层结构代替了PTP模型中的惟一目的地，发送应用程序发布自己的消息，指出消息描述的是有关分层结构中的一个主题的信息。希望接收这些消息的应用程序订阅了这个主题。订阅包含子主题的分层结构中的主题的订阅者可以接收该主题和其子主题发表的所有消息。

　　多个应用程序可以就一个主题发布和订阅消息，而应用程序对其他人仍然是匿名的。MOM 起着代理（broker）的作用，将一个主题已发表的消息路由给该主题的所有订阅者。

2.4 消息中间件产品与JMS

　　从上个世纪90年代初，随着不同厂商消息中间件大量上市，消息中间件技术得到了长足的发展。目前，IBM和BEA的中间件产品在银行、证券、电信等高端行业，以及IT等行业中得到广泛应用。IBM凭借其在1999年推出的应用服务器WebSphere，扎根金融、证券等行业，在超大型以及系统整合型应用方面优势突出；BEA则是专门从事中间件开发的公司，它的应用服务器WebLogic在美国市场占有率超过60％，在国内电信及证券行业占据主要地位；Sun、Oracle、Sybase和Borland等厂商也都有自己的应用服务器；近年来，以金蝶、东方通等公司为代表的国产中间件产品也发展迅速。

　　由于没有统一的规范和标准，基于消息中间件的应用不可移植，不同的消息中间件也不能互操作，这大大阻碍了消息中间件的发展。Java Message Service(JMS, Java消息服务)是SUN及其伙伴公司提出的旨在统一各种消息中间件系统接口的规范。它定义了一套通用的接口和相关语义，提供了诸如持久、验证和事务的消息服务，它最主要的目的是允许Java应用程序访问现有的消息中间件。JMS规范没有指定在消息节点间所使用的通讯底层协议，来保证应用开发人员不用与其细节打交道，一个特定的JMS实现可能提供基于TCP/IP、HTTP、UDP或者其它的协议。

　　目前许多厂商采用并实现了JMS API，现在，JMS产品能够为企业提供一套完整的消息传递功能，下面是一些比较流行的JMS商业软件和开源产品。

1．IBM MQSeries

　　IBM MQ系列产品提供的服务使得应用程序可以使用消息队列进行相互交流，通过一系列基于Java的API，提供了MQSeries在Java中应用开发的方法。它支持点到点和发布/订阅两种消息模式，在基本消息服务的基础上增加了结构化消息类，通过工作单元提供数据整合等内容。

2．WebLogic

　　WebLogic是BEA公司实现的基于工业标准的J2EE应用服务器，支持大多数企业级JavaAPI，它完全兼容JMS规范，支持点到点和发布/订阅消息模式，它具有以下一些特点：

1) 通过使用管理控制台设置JMS配置信息；

2) 支持消息的多点广播；

3) 支持持久消息存储的文件和数据库；

4) 支持XML消息，动态创建持久队列和主题。

3．SonicMQ

　　SonicMQ是Progress公司实现的JMS产品。除了提供基本的消息驱动服务之外，SonicMQ也提供了很多额外的企业级应用开发工具包，它具有以下一些基本特征：

1) 提供JMS规范的完全实现，支持点到点消息模式和发布/订阅消息模式；

2) 支持层次安全管理；

3) 确保消息在Internet上的持久发送；

4) 动态路由构架（DRA）使企业能够通过单个消息服务器动态的交换消息；

5) 支持消息服务器的集群。

4．Active MQ

　　Active MQ是一个基于Apcache 2.0 licenced发布，开放源码的JMS产品。其特点为：

1) 提供点到点消息模式和发布/订阅消息模式；

2) 支持JBoss、Geronimo等开源应用服务器，支持Spring框架的消息驱动；

3) 新增了一个P2P传输层，可以用于创建可靠的P2P JMS网络连接；

4) 拥有消息持久化、事务、集群支持等JMS基础设施服务。

5．OpenJMS

　　OpenJMS是一个开源的JMS规范的实现，它包含以下几个特征：

1) 它支持点到点模型和发布/订阅模型；

2) 支持同步与异步消息发送；

3) 可视化管理界面，支持Applet；

4) 能够与Jakarta Tomcat这样的Servlet容器结合；

5) 支持RMI、TCP、HTTP与SSL协议。

三、消息中间件应用之JMS

　　3.1 JMS简介

　　Java Message Service 规范 1.1 声称：JMS 是一组接口和相关语义，它定义了 JMS 客户如何访问企业消息产品的功能。

　　在 JMS 之前，每一家 MOM 厂商都用专有 API 为应用程序提供对其产品的访问，通常可用于许多种语言，其中包括 Java 语言。JMS 通过 MOM 产品为 Java 程序提供了一个发送和接收消息的标准的、便利的方法。用 JMS 编写的程序可以在任何实现 JMS 标准的 MOM 上运行。

　　JMS 可移植性的关键在于：JMS API 是由 Sun 作为一组接口而提供的。提供了 JMS 功能的产品是通过提供一个实现这些接口的提供者来做到这一点的。开发人员可以通过定义一组消息和一组交换这些消息的客户机应用程序建立 JMS 应用程序。[4]

　　JMS1.0版本于1998年推出，最新的版本是2002发布的JMS 1.1规范。JMS支持消息中间件的两种传递模式：点到点模式和发布-订阅模式。在JMS 1.1以前的版本中，每一种都有自己的特定于该模式的一组客户机接口。JMS1.1版本提供了单一的一组接口，它允许客户机可以在两个模式中发送和接收消息。这些“模式无关的接口”保留了每一个模式的语义和行为，是实现 JMS 客户机的最好选择。

　　统一模式的好处是：

1) 使得用于客户机的编程更简单。

2) 队列和主题的操作可以是同一事务的一部分。

3) 为JMS提供者提供了优化其实现的机会。

　　3.2 JMS体系结构

　　3.2.1 JMS接口描述

　　JMS 支持两种消息类型PTP 和Pub/Sub，分别称作：PTP Domain 和Pub/Sub Domain，这两种接口都继承统一的JMS Parent 接口，JMS 主要接口如下所示：

JMS Parent
PTP Domain
Pub/Sub Domain

ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory

Connection
QueueConnection
TopicConnection

Destination
Queue
Topic

Session
QueueSession
TopicSession

MessageProducer
QueueSender
TopicPublisher

MessageConsumer
QueueReceiver
TopicSubscriber

　　以下是对这些接口的简单描述：

ConnectionFactory：连接工厂，JMS 用它创建连接

Connection：JMS 客户端到JMS Provider 的连接

Destination：消息的目的地

Session：一个发送或接收消息的线程

MessageProducer： 由Session 对象创建的用来发送消息的对象

MessageConsumer： 由Session 对象创建的用来接收消息的对象

3.2.2 JMS消息模型

JMS 消息由以下几部分组成：消息头，属性，消息体。

l 消息头（header）：JMS消息头包含了许多字段，它们是消息发送后由JMS提供者或消息发送者产生，用来表示消息、设置优先权和失效时间等等，并且为消息确定路由。

l 属性（property）：由消息发送者产生，用来添加删除消息头以外的附加信息。

l 消息体（body）：由消息发送者产生，JMS中定义了5种消息体：ByteMessage、MapMessage、ObjectMessage、StreamMessage和TextMessage。

3.3 JMS编程实践

　　广义上说，一个JMS应用是几个JMS 客户端交换消息，开发JMS客户端应用由以下几步构成：

1) 用JNDI 得到ConnectionFactory对象；

2) 用JNDI 得到目标队列或主题对象，即Destination对象；

3) 用ConnectionFactory创建Connection 对象；

4) 用Connection对象创建一个或多个JMS Session；

5) 用Session 和Destination 创建MessageProducer和MessageConsumer；

6) 通知Connection 开始传递消息。

3.3.1 消息生产者编程

　　消息生产者程序如下：

package org.jms.test;

import java.io.*;
import javax.jms.*;
import javax.naming.*;

public class Sender {

public static void main(String[] args) {
new Sender().send();
}

public void send() {
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
try {
//Prompt for JNDI names
System.out.println("Enter ConnectionFactory name:");
String factoryName = reader.readLine();
System.out.println("Enter Destination name:");
String destinationName = reader.readLine();

//Look up administered objects
InitialContext initContext = new InitialContext();
ConnectionFactory factory =
(ConnectionFactory) initContext.lookup(factoryName);
Destination destination = (Destination) initContext.lookup(destinationName);
initContext.close();

//Create JMS objects
Connection connection = factory.createConnection();
Session session =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer sender = session.createProducer(queue);

//Send messages
String messageText = null;
while (true) {
System.out.println("Enter message to send or 'quit':");
messageText = reader.readLine();
if ("quit".equals(messageText))
break;
TextMessage message = session.createTextMessage(messageText);
sender.send(message);
}

//Exit
System.out.println("Exiting...");
reader.close();
connection.close();
System.out.println("Goodbye!");

} catch (Exception e) {
e.printStackTrace();
System.exit(1);
}
}
}

3.3.2 消息消费者编程

消息消费者程序如下：

package compute;
import java.io.*;
import javax.jms.*;
import javax.naming.*;

public class Receiver implements MessageListener {
private boolean stop = false;
public static void main(String[] args) {
new Receiver().receive();
}

public void receive() {
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
try {
//Prompt for JNDI names
System.out.println("Enter ConnectionFactory name:");
String factoryName = reader.readLine();
System.out.println("Enter Destination name:");
String destinationName = reader.readLine();
reader.close();

//Look up administered objects
InitialContext initContext = new InitialContext();
ConnectionFactory factory =
(ConnectionFactory) initContext.lookup(factoryName);
Destination destination = (Destination) initContext.lookup(destinationName);
initContext.close();

//Create JMS objects
Connection connection = factory.createConnection();
Session session =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer receiver = session.createConsumer(queue);
receiver.setMessageListener(this);
connection.start();

//Wait for stop
while (!stop) {
Thread.sleep(1000);
}

//Exit
System.out.println("Exiting...");
connection.close();
System.out.println("Goodbye!");
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
}
}

public void onMessage(Message message) {
try {
String msgText = ((TextMessage) message).getText();
System.out.println(msgText);
if ("stop".equals(msgText))
stop = true;
} catch (JMSException e) {
e.printStackTrace();
stop = true;
}
}
}

　　以上程序都较为简单，基本上为自解释的。

四、消息中间件总结

　　消息中间件自从产生以来发展迅速，在分布式联机事务处理环境中，它担当通讯资源管理器（CRM）的角色，为分布式应用提供实时、高效、可靠的、跨越不同操作系统、不同网络的消息传递服务，同时消息中间件减少了开发跨平台应用程序的复杂性。在要求可靠传输的系统中可以利用消息中间件作为一个通讯平台，向应用提供可靠传输功能来传递消息和文件。

参考文献

[1] 李华琰、郭英奎 著：Java 中间件开发技术 . 中国水利水电出版社，2005

[2] JMS在线教程 . 2004 http://www6.software.ibm.com/developerworks/cn/education/java/j-jms

[3] 基于JMS的消息中间件的研究和设计 . 姚刚. 2006

[4] 消息中间件和JMS . 2005. http://www.huihoo.org/jfox/jfoxmq/mom_jms.html

[5] 基于JMS的数据汇集系统的研究与实现. 2006.

http://www.cndw.com/tech/program/2006042760285.asp

名词解释：
 数据库肯定是要被广大客户所共享访问的，那么在数据库操作过程中很可能出现以下几种不确定情况。
●   更新丢失（Lost update）：两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
●   脏读取（Dirty Reads）：一个事务开始读取了某行数据，但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险的，因为很可能所有的操作都被回滚。
●   不可重复读取（Non-repeatable Reads）：一个事务对同一行数据重复读取两次，但是却得到了不同的结果。例如，在两次读取的中途，有另外一个事务对该行数据进行了修改，并提交。
●   两次更新问题（Second lost updates problem）：无法重复读取的特例。有两个并发事务同时读取同一行数据，然后其中一个对它进行修改提交，而另一个也进行了修改提交。这就会造成第一次写操作失效。
●   虚读（Phantom Reads）：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据（这里并不要求两次查询的SQL语句相同）。这是因为在两次查询过程中有另外一个事务插入数据造成的。
 数据库的隔离级别
       为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。
●   未授权读取（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
●   授权读取（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
●   可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
●   序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

   继续观察，应用还是发生挂起现象，而且大多挂起的时候，db2上没有死锁或者锁等待，这样我们不得不继续分析log，来查看还有什么可疑的问题，并且把日志发给HP和IBM800来寻求支持，HP方很快给出来一些方案，让我们修改OS的一个参数，将OS的参数maxfiles_lim参数调整，从原来的8196调整到16392，这个参数的意思就是一个进程能够使用的最大文件数，但是，这个似乎并不是问题的真正原因，挂起现象依旧每天发生，这时IBM800也给出了反馈，通过分析native_stdout.log发现我们的javaheap峰值最高上升到过1.5G，希望我们检查下我们的javaheap的占用情况。
   我们暂时将javaheap的maxSize调到了1.7G。想起到个治标不治本的作用，调整完之后观察，白天很安静。到了晚上19：30左右，又发生挂起现象了，而且连续几天，都是白天没事，到晚上19：30分左右挂起。这时候，日志报的错误就很固定了，有线程hung住，还有就是oom error , can not create native thread ，这时候IBM800那边发生了一点变化，又原来的男工程师，换成了一位女工程师，这位女工程师很热心，每天都主动打电话来询问情况。
   根据她的分析，应该问题就是出在native heap那块，按照她的建议，首先我们调整了os的一个参数，增加了was进程使用native heap的大小，而且她提到了2个已知的was在hp-ux上运行的bug，一个是socket的，一个是线程池的，这2个问题都会产生一些内存泄露，虽然不知道是不是问题的罪魁祸首，但是还是fix了比较好，socket的bug，她给我提供了一个补丁来修复，线程池的bug，就是在hp-ux上跑websphere，我们webcontainer的线程设置是5-50（初始和max），这样，当系统不繁忙的时候，线程会降下来，这时候就会有内存泄露，这个是websphere的一个bug，她建议我们初始线程池大小和max的一致，这样虽然牺牲了一些性能，但是不会有内存泄露的问题，她还给我发了一些关系was性能相关的文档及监控工具的使用，有几篇关于jvm参数的文档，上面建议，sun的jvm javaheap初始值和最大值设置成一样，hp-ux使用的其实也就是sun的jvm，于是我就更改了下jvm的参数，将java heap的初始值和最大值都设置成了1.5G，并且把permsize设置成了384MB（原来是512MB），设置成这些值是用过hp的一个gc分析工具hpjtune的分析之后设置的。
    更改之后，系统尚未发生线埕挂起现象或者是down机。

理论：
OOM（Out of Memory）。在很多开发人员的开发过程中，或多或少的都会遇到这类问题，这类问题定位比较困难，往往需要根据经验来判断可能出现问题的代码。原因主要是两个：对象没有被释放（多种情况引起，往往是比较隐蔽的引用导致被Hold而无法被回收）。另一种就是真的Memory不够用了，需要增加JVM的Heap来满足应用程序的需求。在Native Heap不够的时候也会发生，同时JVM Heap和Native Heap存在着相互影响和平衡的关系。

OOM
       在其他语言类似于C,Delphi等等由于内存都是由自己分配和管理，因此内存泄露的问题比较常见，同时也是很头痛的一件事情。而Java的对象生命周期管理都是JVM来做的，简化了开发人员的非业务逻辑的处理，但是这种自动管理回收机制也是基于一些规则的，而违背了这些规则的时候，就会造成所谓的“Memory Leak”。
 
OOM(Java Heap)
       错误提示：java.lang.OutOfMemoryError。
这类OOM是由于JVM分配的给应用的Heap Memory已经被耗尽，可能是因为应用在高负荷的情况下的却需要很大的内存，因此可以通过修改JVM参数来增加Java Heap Memory（不过也不能无限制增加，后面那种OOM有可能就是因为这个原因而产生）。另一种情况是因为应用程序使用对象或者资源没有释放，导致内存消耗持续增加，最后出现OOM，这类问题引起的原因往往是应用已不需要的对象还被其他有效对象所引用，那么就无法释放，可能是业务代码逻辑造成的（异常处理不够例如IO等资源），也可能是对于第三方开源项目中资源释放了解不够导致使用以后资源没有释放（例如JDBC的ResultSet等）。
       几个容易出现问题的场景：
       1．应用的缓存或者Collection：如果应用要缓存Java对象或者是在一个Collection中保存对象，那么就要确定是否会有大量的对象存入，要做保护，以防止在大数据量下大量内存被消耗，同时要保证Cache的大小不会无限制增加。
       2．生命周期较长的对象：尽量简短对象的生命周期，现在采用对象的创建释放代价已经很低，同时作了很好的优化，要比创建一个对象长期反复使用要好。如果能够设置超时的情景下，尽量设置超时。
       3．类似于JDBC的Connection Pool，在使用Pool中的对象以后需要释放并返回，不然就会造成Pool的不断增大，在其他Pool中使用也是一样。同样ResultSet，IO这类资源的释放都需要注意。
 
       解决的方法就是查找错误或者是增加Java Heap Memory。      
 
 
OOM(Native Heap)
错误提示：requested XXXX bytes for ChunkPool::allocate. Out of swap space。
       Native Heap Memory是JVM内部使用的Memory，这部分的Memory可以通过JDK提供的JNI的方式去访问，这部分Memory效率很高，但是管理需要自己去做，如果没有把握最好不要使用，以防出现内存泄露问题。JVM 使用Native Heap Memory用来优化代码载入（JTI代码生成），临时对象空间申请，以及JVM内部的一些操作。这次同事在压力测试中遇到的问题就是这类OOM，也就是这类Memory耗尽。同样这类OOM产生的问题也是分成正常使用耗尽和无释放资源耗尽两类。无释放资源耗尽很多时候不是程序员自身的原因，可能是引用的第三方包的缺陷，要确定这类问题，就需要去观察Native Heap Memory的增长和使用情况，在服务器应用起来以后，运行一段时间后JVM对于Native Heap Memory的使用会达到一个稳定的阶段，此时可以看看什么操作对于Native Heap Memory操作频繁，而且使得Native Heap Memory增长，对于Native Heap Memory的情况我还没有找到办法去检测，现在能够看到的就是为JVM启动时候增加-verbose:jni参数来观察对于Native Heap Memory的操作。另一种情况就是正常消耗Native Heap Memory，对于Native Heap Memory的使用主要取决于JVM代码生成，线程创建，用于优化的临时代码和对象产生。当正常耗尽Native Heap Memory时，那么就需要增加Native Heap Memory，此时就会和我们前面提到增加java Heap Memory的情况出现矛盾。
 
应用内存组合
       对于应用来说，可分配的内存受到OS的限制，不同的OS对进程所能访问虚拟内存地址区间直接影响对于应用内存的分配，32位的操作系统通常最大支持4G的内存寻址，而Linux一般为3G，Windows为2G。然而这些大小的内存并不会全部给JVM的Java Heap使用，它主要会分成三部分：Java Heap，Native Heap，载入资源和类库等所占用的内存。那么由此可见，Native Heap和 Java Heap大小配置是相互制约的，哪一部分分配多了都可能会影响到另外一部分的正常工作，因此如果通过命令行去配置，那么需要确切的了解应用使用情况，否则采用默认配置自动监测会更好的优化应用使用情况。
       同样要注意的就是进程的虚拟内存和机器的实际内存还是有区别的，对于机器来说实际内存以及硬盘提供的虚拟内存都是提供给机器上所有进程使用的，因此在设置JVM参数时，它的虚拟内存绝对不应该超过实际内存的大小。

  JVM优化配置
Garbage Collector Policy：
       在Jdk提供了三种GC，除了原来提供的串行GC（SerialGC）以外，还提供了两种新的GC：ParallelGC和ConcMarkSweepGC。ParallelGC采用了多线程并行管理和回收垃圾对象，提高了回收效率，提高了服务器的吞吐量，适合于多处理器的服务器。ConcMarkSweepGC采用的是并发方式来管理和回收垃圾对象，降低垃圾回收产生的响应暂停时间。这里说一下并发和并行的区别，并发指的是多个进程并行执行垃圾回收，那么可以很好的利用多处理器，而并行指的是应用程序不需要暂停可以和垃圾回收线程并发工作。串行GC适合小型应用和单处理器系统（无需多线程交互，效率比较高），后两者适合大型系统。
       使用方式就是在参数配置中增加-XX:+UseParallelGC等方式来设置。
       对于这部分的配置在网上有很多的实例可以参考，不过最终采用哪一种GC还是要根据具体的情况来分析和选择。
 
Heap：
       OOM的各种经历已经让每一个架构师开发人员看到了了解Heap的重要性。OOM已经是Heap的临界点，不得不引起注意，然而Heap对于性能的潜在影响并未被引起重视，不过和GC配置一样，在没有对使用情况作仔细分析和研究的情况下，贸然的去修改Heap配置，可能适得其反，这里就来看一下Heap的一些概念和对于性能的影响。
       我们的应用所能够得到的最大的Heap受三部分因素的制约：数据处理模型（32位或者64位操作系统），系统地虚拟内存总数和系统的物理内存总数。首先Heap的大小不能超过不同操作系统的进程寻址范围，当前大部分系统最高限度是4G，Windows通常是2G，Linux通常是3G。系统的虚拟内存也是分配的依据，首先是不能超过，然后由于操作系统支持硬盘来做部分的虚拟内存，如果设置过大，那么对于应用响应来说势必有影响。再则就是要考虑同一台服务器上运行多个Java虚拟机所消耗的资源总合也不能超过可用资源。就和前面OOM分析中的一样，其实由于OS的数据处理模型的限制，机器本身的硬件内存资源和虚拟内存资源并不一定会匹配，那么在有限的资源下如何调整好资源分配，对于应用来说尤为重要。感觉很像魔兽里面的天赋点。通过理论和实践来分配HEAP，让系统达到最佳的状态。
 
 
关于Heap的几个参数设置：
       说了Heap的有限资源问题以后，就来看看如何通过配置去改变JVM对于Heap的分配。下面所说的主要是对于Java Heap的分配，那么在申请了Java Heap以后，剩下的可用资源就会被使用到Native Heap。
       Xms: java heap初始化时的大小。默认情况是机器物理内存的1/64。这个主要是根据应用启动时消耗的资源决定，分配少了申请起来会降低启动速度，分配多了也浪费。
       Xmx:java heap的最大值，默认是机器物理内存的1/4，最大也就到1G。这个值决定了最多可用的Java Heap Memory，分配过少就会在应用需要大量内存作缓存或者零时对象时出现OOM的问题，如果分配过大，那么就会产生上文提到的第二类OOM。所以如何配置还是根据运行过程中的分析和计算来确定，如果不能确定还是采用默认的配置。
       Xmn:java heap新生代的空间大小。在GC模型中，根据对象的生命周期的长短，产生了内存分代的设计：青年代（内部也分成三部分，类似于整体划分的作用，可以通过配置来设置比例），老年代，持久代。每一代的管理和回收策略都不相同，最为活跃的就是青年代，同时这部分的内存分配和管理效率也是最高。通常情况下，对于内存的申请优先在新生代中申请，当内存不够时会整理新生代，当整理以后还是不能满足申请的内存，就会向老年代移动一些生命周期较长的对象。这种整理和移动会消耗资源，同时降低系统运行响应能力，因此如果青年代设置的过小，就会频繁的整理和移动，对性能造成影响。那是否把年青代设置的越大越好，其实不然，年青代采用的是复制搜集算法，这种算法必须停止所有应用程序线程，服务器线程切换时间就会成为应用响应的瓶颈（当然永远不用收集那么就不存在这个问题）。老年代采用的是串行标记收集的方式，并发收集可以减少对于应用的影响。
       Xss:线程堆栈最大值。允许更多的虚拟内存空间地址被Java Heap使用。
 
以下是sun公司的性能优化白皮书中提到的几个例子：
 
1．对于吞吐量的调优。机器配置：4G的内存，32个线程并发能力。
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
       -Xmx3800m -Xms3800m 配置了最大Java Heap来充分利用系统内存。
       -Xmn2g 创建足够大的青年代（可以并行被回收）充分利用系统内存，防止将短期对象复制到老年代。
    -Xss128 减少默认最大的线程栈大小，提供更多的处理虚拟内存地址空间被进程使用。
    -XX:+UseParallelGC 采用并行垃圾收集器对年青代的内存进行收集，提高效率。
    -XX:ParallelGCThreads=20 减少垃圾收集线程，默认是和服务器可支持的线程最大并发数相同，往往不需要配置到最大值。
 
2．尝试采用对老年代并行收集
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-Xmx3550m -Xms3550m 内存分配被减小，因为ParallelOldGC会增加对于Native Heap的需求，因此需要减小Java Heap来满足需求。
-XX:+UseParallelOldGC 采用对于老年代并发收集的策略，可以提高收集效率。
 
3．提高吞吐量，减少应用停顿时间
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31
 
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 选择了并发标记交换收集器，它可以并发执行收集操作，降低应用停止时间，同时它也是并行处理模式，可以有效地利用多处理器的系统的多进程处理。
 
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=31 表示在青年代中Eden和Survivor比例，设置增加了Survivor的大小，越大的survivor空间可以允许短期对象尽量在年青代消亡。
 
-XX:TargetSurvivorRatio=90 允许90%的空间被占用，超过默认的50%，提高对于survivor的使用率。

以上这些其实都是治标不治本。重要的是程序中是否有导致OOM的CODE。
从整个事件分析和处理的过程，除去最先的websphere中JMS的BUG以及WEBSPHERE在HP-UX运行时线程降低产生的BUG外。
更重要的是java heap和native heap分配方面。一开始报OOM的错，同事增大了java heap。但反到产生了负面效果。是因为程序中有大查询。当初始化这种大查询对象的时候，又需要native heap，而这时native heap又不够用了。这时候平均分配了这两个HEAP。
目前来说，HEAP看似够用了。但还需要从程序中查找出这种大结果集，来优先程序。对于编写代码本身来说，对于访问DB资源，一定要尽可能晚地访问关键资源，尽可能快地提交工作，尽可能使用分页查询。这样才会最大程度的避免死锁以及OOM。