构建可扩展的Java EE应用（一） - 编程入门网
| 可思议 的低。那么这些CPU都在干嘛呢？它们不是在忙吗，那么它们到底在忙些什么呢？ 通过OS的跟踪工具，我们发现几乎所有的CPU都在干同一件事-- "HashMap.get()" ，看起来所有的CPU都进入了死循环，之后我们在不同数量的CPU的服务器上再测 试了这个应用，结果表明，服务器拥有越多CPU，那么产生死循环的概率就会越高 。
产生这个死循环的根源在于对一个未保护的共享变量 -- 一个"HashMap"数据 结构的操作。当在所有操作的方法上加了"synchronized"后，一切恢复了正常。 检查"HashMap"(Java SE 5.0)的源码，我们发现有潜在的破坏其内部结构最终造 成死循环的可能。在下面的代码中，如果我们使得HashMap中的entries进入循环 ，那么"e.next()"永远都不会为null。 Code list 7:
public V get(Object key) { if (key == null) return
getForNullKey(); int hash = hash(key.hashCode()); for
(Entry<K,V> e = table[indexFor(hash, table.length)];
e != null; e = e.next) { Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
return e.value; } return null;}
不仅get()方法会这样，put()以及其他对外暴露的方法都会有这个风险，这算 jvm的bug吗？应该说不是的，这个现象很早以前就报告出来了（详细见： http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457）。Sun的工程 师并不认为这是bug，而是建议在这样的场景下应采用"ConcurrentHashMap"，在 构建可扩展的系统时应将这点纳入规范中。 构建可扩展的Java EE应用（一）(6)时间:2011-07-08 blogjava BlueDavy非阻塞 IO vs. 阻塞IO Java 1.4中引入的java.nio包，允许开发人员在进行数据处理时获取更好的性 能并提供更好的扩展性。NIO提供的非阻塞IO操作允许java应用像其他底层语言（ 例如c）一样操作IO。目前已经有很多NIO的框架（例如Apache的Mina、Sun的 Grizzly）了被广泛的使用在很多的项目和产品中。 在最近的5个月内，我们实验室有两个Java EE项目测试对比了基于传统的阻塞 I/O构建的服务器和非阻塞I/O构建的服务器上的性能。他们选择了Tomcat 5作为 基于阻塞I/O的服务器，Glassfish作为基于非阻塞I/O的服务器。 首先，他们测试了一些简单的JSP页面和servlets，得到如下结果：（在一台4 CPU的服务器上）
从测试结果来看，Glassfish的性能远低于Tomcat。客户对非阻塞I/O能够带来 的提升表示怀疑，但为什么那么多的文章以及技术报告都告诉大家NIO具备更好的 性能和可扩展性呢？ 当在更多的场景进行测试后，随着NIO的能力逐步的展现出来，他们改变了观 点，他们做了以下的测试： 1、比简单的JSP、servlet更为复杂的场景，包括EJB、数据库、文件IO、JMS 和事务； 2、模拟更多的并发用户，从1000到10000； 3、在不同的硬件环境上进行测试，从2 CPU、4 CPU到16 CPU。 以下的图为在4 CPU服务器上的测试结 |
||||||||||||||||||||
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
||||||||||||||||||||
