shidcai-CSDN博客

转载 Kerberos的原理

这是MIT（Massachusetts Institute of Technology）为了帮助人们理解Kerberos的原理而写的一篇对话集。里面有两个虚构的人物：Athena和Euripides，通过Athena不断的构思和Euripides不断的寻找其中的漏洞，使大家明白了Kerberos协议的原理。 Athena: 雅典娜，智慧与技艺的女神。 Euripides:欧里庇得斯, 希腊的悲

2006-09-08 14:19:00 2893 1

原创 java之内存泄漏

内存泄漏的问题也是老生常谈的问题。C++由于内存的分配和回收都是由程序员自己管理的，coding的时候小心些，出现内存泄漏的几率就会很小。而java由于使用了GC，由GC自动去回收无用的内存，内存的管理似乎变得很简单。但是，如果不知道GC的工作原理，一旦出现内存泄漏的问题，就十分头痛了；即使知道了GC的工作原理，解决内存泄漏也是一件繁琐的工作。当然，了解GC的基本工作原理，对解决内存泄漏

2006-04-17 02:36:00 3097 1

原创 Java NIO是否到处都适合？

为了实现高性能的MOM（消息中间件），学习了java的NIO，想利用NIO技术来改善网络通讯的性能。学习NIO的时候，看了书上的，也找了网上相当多的资源，但大部分的资料都是比较粗浅的，入门级，深入的基本没有。不过，对于了解和学习NIO来说已经足够了。真正的领会还是需要在实践中获得的。 NIO的技术在JDK1.4中出现。NIO最大的特点有两个：一个是块状读写；另外一个是多路

2006-03-19 18:46:00 4854 7

原创流量控制器＋消息cache实现高性能稳定的MQ服务器

本来想把MQ的消息cache改造过程详细写写，由于到年关了，项目要验收了，时间紧得很，只好把新的想法写下来，原来的改造想法就先搁着吧，等有空了再说（估计是不会有空的了）。消息cache对MQ性能的影响是不必说了，肯定是导致MQ性能下降的一个重大原因。既然不能抛弃它，那就好好利用它。如果能在资源宽裕的情况下不使用消息cache，保持MQ的性能；而只有在资源吃紧的情况下

2006-01-17 23:55:00 4920 4

原创消息cache，我真得需要你吗（2）？

本来写blog的时候并没有想到会有多少人看到，所以，只是把所想的写下来。后来，发现有很多热心的人给我的问题提了很多意见，心里很是感激。想想同仁的意见如果可以帮我改进JTangMQ的设计，那真得是求之不得的事情，亦或是我写的东西对其他人也有参考价值，那是我的莫大荣幸了。那就继续把所想的写下来吧。上篇提到，消息cache引出的两个问题令人十分头痛，它的的确确影响着JTan

2006-01-15 00:31:00 2318 2

原创消息cache，我真得需要你吗（1）？

由于JTangMQ提供的消息服务是异步的服务，消息的发送者和接收者可以不需要时刻在线或同时在线，也不需要知道彼此的身份，发送者和接收者只需要同MQ的服务器进行交互。因此，在实际应用中可能会出现两种场景：一是消息的发送者和接收者同时在线并分别不断进行收发操作。此时，对于服务器来说有一个消息接收流量和消息发送流量，如果消息接收流量大于消息发送流量，则服务器上的消息数就会越来越多，最终将

2006-01-12 00:24:00 3965 5

原创 JTangMQ的现在和未来

原本打算今天只是想写写JTangMQ接下来的改造计划，正思考着，接到吴健老师打来的电话，需要我提供一些JTangMQ的相关资料，那就干脆写一下JTangMQ的目前的情况以及将来的改造思路。消息中间件的出现大概已经快有七八的历史了（具体什么时间开始还没考证）。起初的时候，各个厂家由于没有统一的标准，也出于企业的private的目的，各个消息产品都有自己的api和架构，彼此之间并不相容。

2006-01-08 00:16:00 3422 1

原创线程的上下文开销真得那么厉害吗（2）？

线程切换的开销的确是比较厉害的。这是从今天的实验中得出的结果。为了解决上次提出的疑问，今天在实验室做了一个试验，来测试线程的切换是否开销比较大。由于主要是为了比较线程的数目多少对性能的影响，所以，具体的测试环境就不提了，只要每次实验在同等的条件下即可。首先，在MQ的Server端启动100个读线程，100个写线程，100个消息deliver线程，客户端同

2006-01-07 23:04:00 10531 9

原创线程的上下文开销真得那么厉害吗（1）？

终究还是郁闷着了，为了JTangMQ的性能。都是因为MQ，这个令人又爱又恨的家伙。想起当初刚刚开始设计JTangMQ的豪言壮志，为MQ设计、coding的三百多个日夜历历在目，如今却坐在椅子上一声叹息。为何JTangMQ的性能还是那么不尽如人意？为什么呢？最初的设计目标是“超过国产MQ，迈向SonicMQ”，而现在的产品同JBossMQ相比还有那么一点的差距。这个差距

2006-01-07 00:11:00 7813 18

原创 JTangMQ开发历史

2004年11月 J2EE应用服务器立项，阅读JMS规范12月收集关于JMS的OpenSource和现有的MQ产品 2005年1月确定分析JBossMQ，UberMQ和OpenJMS的源码3月总结和汇报源码分析成果，并开始对JBossMQ，WebloigMQ，SonicMQ等的测试4月命名J2EE应用服务器为JTang，JMS实现为J

2005-07-21 00:27:00 2671

方木空间