想JAVA企业级应用一路走来，从J2ee到Java EE5 在到即将要推出的Java EE6经历了一个由复杂到简单，由繁到简的过程。
Reza Rahman 文章说，Java EE6将会更简单，更轻量级，更易部署，Java EE6将会裁剪到Java EE5中不实用的部分。并且Java EE6将会为不同的用户群提供不同的规范子集。
回顾上一版本Java EE 5中，主要引入了以下改变：
1）引入了EJB3.0
2）引入了JSF作Tier framework.
3）使用JAX-WS2.0取代了JAX-RPC作新一代的SOAP的Web service API
4）使用POJO编程，零配置系统和自由的XML减轻了系统的复杂性。
(8 人打了分，平均分： 2.75 )
Loading...下面是号称最好的50套WEB开发的图标。来源：链接
其它相关的一些文章
(16 人打了分，平均分： 3.63 )Loading...07年12月，我写了一篇《C++虚函数表解析》的文章，引起了大家的兴趣。有很多朋友对我的文章留了言，有鼓励我的，有批评我的，还有很多问问题的。我在这里一并对大家的留言表示感谢。这也是我为什么再写一篇续言的原因。因为，在上一篇文章中，我用了的示例都是非常简单的，主要是为了说明一些机理上的问题，也是为了图一些表达上方便和简单。不想，这篇文章成为了打开C++对象模型内存布局的一个引子，引发了大家对C++对象的更深层次的讨论。当然，我之前的文章还有很多方面没有涉及，从我个人感觉下来，在谈论虚函数表里，至少有以下这些内容没有涉及：
1）有成员变量的情况。
2）有重复继承的情况。
3）有虚拟继承的情况。
4）有钻石型虚拟继承的情况。
这些都是我本篇文章需要向大家说明的东西。所以，这篇文章将会是《C++虚函数表解析》的一个续篇，也是一篇高级进阶的文章。我希望大家在读这篇文章之前对C++有一定的基础和了解，并能先读我的上一篇文章。因为这篇文章的深度可能会比较深，而且会比较杂乱，我希望你在读本篇文章时不会有大脑思维紊乱导致大脑死机的情况。;-)
简而言之，我们一个类可能会有如下的影响因素：
1）成员变量
2）虚函数（产生虚函数表）
3）单一继承（只继承于一个类）
4）多重继承（继承多个类）
5）重复继承（继承的多个父类中其父类有相同的超类）
6）虚拟继承（使用virtual方式继承，为了保证继承后父类的内存布局只会存在一份）
上述的东西通常是C++这门语言在语义方面对对象内部的影响因素，当然，还会有编译器的影响（比如优化），还有字节对齐的影响。在这里我们都不讨论，我们只讨论C++语言上的影响。
本篇文章着重讨论下述几个情况下的C++对象的内存布局情况。
(26 人打了分，平均分： 4.00 )Loading...C++中的虚函数的作用主要是实现了多态的机制。关于多态，简而言之就是用父类型别的指针指向其子类的实例，然后通过父类的指针调用实际子类的成员函数。这种技术可以让父类的指针有“多种形态”，这是一种泛型技术。所谓泛型技术，说白了就是试图使用不变的代码来实现可变的算法。比如：模板技术，RTTI技术，虚函数技术，要么是试图做到在编译时决议，要么试图做到运行时决议。
关于虚函数的使用方法，我在这里不做过多的阐述。大家可以看看相关的C++的书籍。在这篇文章中，我只想从虚函数的实现机制上面为大家 一个清晰的剖析。
当然，相同的文章在网上也出现过一些了，但我总感觉这些文章不是很容易阅读，大段大段的代码，没有图片，没有详细的说明，没有比较，没有举一反三。不利于学习和阅读，所以这是我想写下这篇文章的原因。也希望大家多给我提意见。
言归正传，让我们一起进入虚函数的世界。
对C++ 了解的人都应该知道虚函数（Virtual Function）是通过一张虚函数表（Virtual Table）来实现的。简称为V-Table。在这个表中，主是要一个类的虚函数的地址表，这张表解决了继承、覆盖的问题，保证其容真实反应实际的函数。这样，在有虚函数的类的实例中这个表被分配在了这个实例的内存中，所以，当我们用父类的指针来操作一个子类的时候，这张虚函数表就显得由为重要了，它就像一个地图一样，指明了实际所应该调用的函数。
这里我们着重看一下这张虚函数表。C++的编译器应该是保证虚函数表的指针存在于对象实例中最前面的位置（这是为了保证取到虚函数表的有最高的性能——如果有多层继承或是多重继承的情况下）。 这意味着我们通过对象实例的地址得到这张虚函数表，然后就可以遍历其中函数指针，并调用相应的函数。
听我扯了那么多，我可以感觉出来你现在可能比以前更加晕头转向了。 没关系，下面就是实际的例子，相信聪明的你一看就明白了。
(34 人打了分，平均分： 4.15 )Loading...在我们用C/C++开发的过程中，总是有一个问题会给我们带来苦恼。这个问题就是函数内和函数外代码需要通过一块内存来交互（比如，函数返回字符串），这个问题困扰和很多开发人员。如果你的内存是在函数内栈上分配的，那么这个内存会随着函数的返回而被弹栈释放，所以，你一定要返回一块函数外部还有效的内存。
这是一个让无数人困扰的问题。如果你一不小心，你就很有可能在这个上面犯错误。当然目前有很多解决方法，如果你熟悉一些标准库的话，你可以看到许多各式各样的解决方法。大体来说有下面几种：
1）在函数内部通过malloc或new在堆上分配内存，然后把这块内存返回（因为在堆上分配的内存是全局可见的）。这样带来的问题就是潜在的内存问题。因为，如果返回出去的内存不释放，那么就是memory Leak。或者是被多次释放，从而造成程序的crash。这两个问题都相当的严重，所以这种设计方法并不推荐。（在一些Windows API中，当你调用了一些API后，你必需也要调用他的某些API来释放这块内存）
2）让用户传入一块他自己的内存地址，而在函数中把要返回的内存放到这块内存中。这是一个目前普遍使用的方式。很多Windows API函数或是标准C函数都需要你传入一个buffer和这个buffer的长度。这种方式对我们来说应该是屡见不鲜了。这种方式的好处就是由函数外部的程序来维护这块内存，比较简显直观。但问题就是在使用上稍许有些麻烦。不过这种方式把犯错误的机率减到了最低。
3）第三种方式显得比较另类，他利用了static的特性，static的栈内存一旦分配，那这块内存不会随着函数的返回而释放，而且，它是全局可见的（只要你有这块内存的地址）。所以，有一些函数使用了static的这个特性，即不用使用堆上的内存，也不需要用户传入一个buffer和其长度。从而，使用得自己的函数长得很漂亮，也很容易使用。
这里，我想对第三个方法进行一些讨论。使用static内存这个方法看似不错，但是它有让你想象不到的陷阱。让我们来用一个实际发生的案例来举一个例子吧。
(22 人打了分，平均分： 3.50 )Loading...Scott Meyers在《More Effective C++》中举了个例子，不知你是否还记得？在你还在上学的时候，你的父母要你不要看电视，而去复习功课，于是你把自己关在房间里，做出一副正在复习功课的样子，其实你在干着别的诸如给班上的某位女生写情书之类的事，而一旦你的父母出来在你房间要检查你是否在复习时，你才真正捡起课本看书。这就是“拖延战术”，直到你非要做的时候才去做。
当然，这种事情在现实生活中时往往会出事，但其在编程世界中摇身一变，就成为了最有用的技术，正如C++中的可以随处声明变量的特点一样，Scott Meyers推荐我们，在真正需要一个存储空间时才去声明变量（分配内存），这样会得到程序在运行时最小的内存花销。执行到那才会去做分配内存这种比较耗时的工作，这会给我们的程序在运行时有比较好的性能。必竟，20%的程序运行了80%的时间。
当然，拖延战术还并不只是这样一种类型，这种技术被我们广泛地应用着，特别是在操作系统当中，当一个程序运行结束时，操作系统并不会急着把其清除出内存，原因是有可能程序还会马上再运行一次（从磁盘把程序装入到内存是个很慢的过程），而只有当内存不够用了，才会把这些还驻留内存的程序清出。
写时才拷贝（Copy-On-Write）技术，就是编程界“懒惰行为”——拖延战术的产物。举个例子，比如我们有个程序要写文件，不断地根据网络传来的数据写，如果每一次fwrite或是fprintf都要进行一个磁盘的I/O操作的话，都简直就是性能上巨大的损失，因此通常的做法是，每次写文件操作都写在特定大小的一块内存中（磁盘缓存），只有当我们关闭文件时，才写到磁盘上（这就是为什么如果文件不关闭，所写的东西会丢失的原因）。更有甚者是文件关闭时都不写磁盘，而一直等到关机或是内存不够时才写磁盘，Unix就是这样一个系统，如果非正常退出，那么数据就会丢失，文件就会损坏。
呵呵，为了性能我们需要冒这样大的风险，还好我们的程序是不会忙得忘了还有一块数据需要写到磁盘上的，所以这种做法，还是很有必要的。
(45 人打了分，平均分： 4.22 )Loading...