一、API网关的用处

API网关我的分析中会用到以下三种场景。 

1. Open API。 企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开放平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。
2. 微服务网关。微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。 
3. API服务管理平台。上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。 API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。

二、API网关在企业整体架构中的地位

一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。 因此在我的设计中将这三种应用分别用不同的网关进行API管理，分别是：API网关（OpenAPI合伙伙伴应用）、API网关（内部应用）、API网关（内部公网应用）。

三、企业中在如何应用API网关

1、对于OpenAPI使用的API网关来说，一般合作伙伴要以应用的形式接入到OpenAPI平台，合作伙伴需要到 OpenAPI平台申请应用。 因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。 如下架构:

当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。 

2、对于内网的API网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的API服务治理平台。 当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。 而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理，那么API网关起到的就是API服务治理的作用。 架构参考如下：

3、对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致，在架构上是可能由独立的API网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的API网关。 如果使用独立的API网关，有以下的好处：

• 面向合作伙伴和面向公司主体业务的优先级不一样，不同的API网关可以做到业务影响的隔离。
• 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
• 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

四、API网关有哪些竞争方案

1、对于Open API平台的API网关，我分析只能选择API网关作为解决方案，业界没有发现比较好的可以用来作为Open API平台的入口的其他方案。 

2、对于作为微服务网关的API网关，业界的选择可以选择的解决方案比较多，也取决于微服务器的实现方案，有一些微服务架构的实现方案是不需要微服务网关的。

• Service Mesh，这是新兴的基于无API网关的架构，通过在客户端上的代理完成屏蔽网络层的访问，这样达到对应用层最小的改动，当前Service Mesh的产品还正在开发中，并没有非常成熟可直接应用的产品。 发展最迅速的产品是Istio。 建议大家密切关注相关产品的研发、业务使用进展。

• 基于duboo架构，在这个架构中通常是不需要网关的，是由客户端直接访问服务提供方，由注册中心向客户端返回服务方的地址。

五、API网关解决方案

私有云开源解决方案如下：

• Kong kong是基于Nginx+Lua进行二次开发的方案， https://konghq.com/
• Netflix Zuul，zuul是spring cloud的一个推荐组件，https://github.com/Netflix/zuul
• orange,这个开源程序是国人开发的， http://orange.sumory.com/

公有云解决方案：

• Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/
• 阿里云API网关，https://www.aliyun.com/product/apigateway/
• 腾讯云API网关， https://cloud.tencent.com/product/apigateway

自开发解决方案：

• 基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于这个方案
• 基于Netty、非阻塞IO模型。 通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。
• 基于Node.js的方案。 这种方案是应用了Node.js天生的非阻塞的特性。
• 基于java Servlet的方案。 zuul基于的就是这种方案，这种方案的效率不高，这也是zuul总是被诟病的原因。

六、企业怎么选择API网关

如果是要选择一款已有的API网关，那么需要从以下几个方面去考虑。 

1、性能与可用性
如果一旦采用了API网关，那么API网关就会作为企业应用核心，因此性能和可用性是必须要求的。

• 从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要10ms以下。 系统需要采用非阻塞的IO，如epoll，NIO等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Node.js的响应式编程和基于java体现的RxJava和Future。
• 网关必须支持集群部署，任务一台服务器的crash都应该不影响整体系统的可用性。
• 多套网关应该支持同一管理平台和同一监控中心。 如： 一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

2、可扩展性、可维护性
一款产品总有不能满足生产需求的地方，因此需求思考产品在如何进行二次开发和维护，是否方便公司团队接手维护产品。 
3、需求匹配度
需要评估各API网关在需求上是否能满足，如： 如果是OpenAPI平台需要使用API网关，那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。 如果是微服务网关，那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。
4、是否开源？公司是否有自开发的能力？
现有的开源产品如kong，zuul，orange都有基础的API网关的核心功能，这些开源产品大多离很好的使用有一定的距离，如：没有提供管理功能的UI界面、监控功能弱小，不支持OpenAPI平台，没有公司运营与运维的功能等。 当然开源产品能获取源代码，如果公司有比较强的研发能力，能hold住这些开源产品，经过二次开发kong、zuul应该还是适应一些公司，不过需求注意以下一些点：

• kong是基于ngnix+lua的，从公司的角度比较难于找到能去维护这种架构产品的人。 需求评估当前公司是否有这个能力去维护这个产品。
• zuul因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配zuul的监控和管理系统。
• orange由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。

另外kong提供企业版本的API网关，当然也是基于ngnix+lua的，企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。

5、公有云还是私有云
现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关，当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满足部分用户的定制需求了。另外很多企业因为自身信息安全的原因，不能使用外网公有网的API网关服务，这样就只有选择私有云的方案了。 
在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用，无法做到定制的合作伙伴门户，这也不适合于部分企业的需求。 
如果作为微服务网关，大多数情况下是希望网关服务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的API网关才能满足需求。 

综合上面的分析，基础公有云的API网关只有满足一部分简单客户的需求，对于很多企业来说私有云的API网关才是正确的选择。

文章作者介绍：
来自于小豹科技的架构师-专注于软件研发基于平台性软件的研发，目前我正在研发一款基于Netty、响应式架构的插件式的API网关，希望能对行业带来一些改变。 我希望与对OpenAPI、微服务、API网关、Service Mesh等感兴趣的朋友多交流。 有兴趣的朋友请加我的QQ群244054462。

Internet的快速增长使多媒体网络服务器，特别是Web服务器，面对的访问者数量快速增加，网络服务器需要具备提供大量并发访问服务的能力。 例如Yahoo每天会收到数百万次的访问请求，因此对于提供大负载Web服务的服务器来讲，CPU、I/O处理能力很快会成为瓶颈。

简单的 提高硬件性能并不能真正解决这个问题，因为单台服务器的性能总是有限的，一般来讲，一台PC服务器所能提供的并发访问处理能力大约为1000个，更为高档 的专用服务器能够支持3000-5000个并发访问，这样的能力还是无法满足负载较大的网站的要求。尤其是网络请求具有突发性，当某些重大事件发生时，网 络访问就会急剧上升，从而造成网络瓶颈，例如在网上发布的克林顿弹劾书就是很明显的例子。必须采用多台服务器提供网络服务，并将网络请求分配给这些服务器 分担，才能提供处理大量并发服务的能力。

当使用多台服务器来分担负载的时候，最简单的办法是将不同的服务器用在不同的方面。 按提供的内容进行分割时，可以将一台服务器用于提供新闻页面，而另一台用于提供游戏页面；或者可以按服务器的功能进行分割，将一台服务器用于提供静态页面 访问，而另一些用于提供CGI等需要大量消耗资源的动态页面访问。然而由于网络访问的突发性，使得很难确定那些页面造成的负载太大，如果将服务的页面分割 的过细就会造成很大浪费。事实上造成负载过大的页面常常是在变化中的，如果要经常按照负载变化来调整页面所在的服务器，那么势必对管理和维护造成极大的问 题。因此这种分割方法只能是大方向的调整，对于大负载的网站，根本的解决办法还需要应用负载均衡技术。

负载均衡的思路下多台 服务器为对称方式，每台服务器都具备等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。然后通过某种负载分担技术，将外部发送来的请求均匀分配 到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。由于建立内容完全一致的Web服务器并不复杂，可以使用服务器同步更新或者 共享存储空间等方法来完成，因此负载均衡技术就成为建立一个高负载Web站点的关键性技术。

1. 基于特定服务器软件的负载均衡

   很 多网络协议都支持“重定向”功能，例如在HTTP协议中支持Location指令，接收到这个指令的浏览器将自动重定向到Location指明的另一个 URL上。由于发送Location指令比起执行服务请求，对Web服务器的负载要小的多，因此可以根据这个功能来设计一种负载均衡的服务器。任何时候 Web服务器认为自己负载较大的时候，它就不再直接发送回浏览器请求的网页，而是送回一个Locaction指令，让浏览器去服务器集群中的其他服务器上 获得所需要的网页。

   在这种方式下，服务器本身必须支持这种功能，然而具体实现起来却有很多困难，例如一台服务器如何能保证它重定向过的服务 器是比较空闲的，并且不会再次发送Location指令？Location指令和浏览器都没有这方面的支持能力，这样很容易在浏览器上形成一种死循环。因 此这种方式实际应用当中并不多见，使用这种方式实现的服务器集群软件也较少。有些特定情况下可以使用CGI（包括使用FastCGI或mod_perl扩 展来改善性能）来模拟这种方式去分担负载，而Web服务器仍然保持简洁、高效的特性，此时避免Location循环的任务将由用户的CGI程序来承担。

2. 基于DNS的负载均衡

   由 于基于服务器软件的负载均衡需要改动软件，因此常常是得不偿失，负载均衡最好是在服务器软件之外来完成，这样才能利用现有服务器软件的种种优势。最早的负 载均衡技术是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个 名字时得到其中的一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，他们也就访问不同地址上的Web服务器，从而达到负载均衡的目的。

   

   例如如果希望使用三个Web服务器来回应对www.exampleorg.org.cn的HTTP请求，就可以设置该域的DNS服务器中关于该域的数据包括有与下面例子类似的结果：

   www1		IN		A 		192.168.1.1

   www2		IN		A 		192.168.1.2

   www3		IN		A 		192.168.1.3

   www		IN		CNAME		www1

   www		IN		CNAME		www2

   www		IN		CNAME		www3

   此后外部的客户机就可能随机的得到对应www的不同地址，那么随后的HTTP请求也就发送给不同地址了。

   DNS 负载均衡的优点是简单、易行，并且服务器可以位于互联网的任意位置上，当前使用在包括Yahoo在内的Web站点上。然而它也存在不少缺点，一个缺点是为 了保证DNS数据及时更新，一般都要将DNS的刷新时间设置的较小，但太小就会造成太大的额外网络流量，并且更改了DNS数据之后也不能立即生效；第二点 是DNS负载均衡无法得知服务器之间的差异，它不能做到为性能较好的服务器多分配请求，也不能了解到服务器的当前状态，甚至会出现客户请求集中在某一台服 务器上的偶然情况。

3. 反向代理负载均衡

   使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速 模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术，让代理服务器将请求均匀转发给多台内部Web服务器之一上，从而达到负载均衡的目的。 这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因 此也被称为反向代理模式。

   实现这个反向代理能力并不能算是一个特别复杂的任务，但是在负载均衡中要求特别高的效率，这样实现起来就不是十分 简单的了。每针对一次代理，代理服务器就必须打开两个连接，一个为对外的连接，一个为对内的连接，因此对于连接请求数量非常大的时候，代理服务器的负载也 就非常之大了，在最后反向代理服务器会成为服务的瓶颈。例如，使用Apache的mod_rproxy模块来实现负载均衡功能时，提供的并发连接数量受 Apache本身的并发连接数量的限制。一般来讲，可以使用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，例如搜寻。

   使 用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能，具备额外的安全性，外部客户不能直接访问真实的服务器。并且 实现起来可以实现较好的负载均衡策略，将负载可以非常均衡的分给内部服务器，不会出现负载集中到某个服务器的偶然现象。

4. 基于NAT的负载均衡技术

   网 络地址转换为在内部地址和外部地址之间进行转换，以便具备内部地址的计算机能访问外部网络，而当外部网络中的计算机访问地址转换网关拥有的某一外部地址 时，地址转换网关能将其转发到一个映射的内部地址上。因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址，此后外部网络中的计算机就各自与 自己转换得到的地址上服务器进行通信，从而达到负载分担的目的。

   

   地 址转换可以通过软件方式来实现，也可以通过硬件方式来实现。使用硬件方式进行操作一般称为交换，而当交换必须保存TCP连接信息的时候，这种针对OSI网 络层的操作就被称为第四层交换。支持负载均衡的网络地址转换为第四层交换机的一种重要功能，由于它基于定制的硬件芯片，因此其性能非常优秀，很多交换机声 称具备400MB-800MB的第四层交换能力，然而也有一些资料表明，在如此快的速度下，大部分交换机就不再具备第四层交换能力了，而仅仅支持第三层甚 至第二层交换。

   然而对于大部分站点来讲，当前负载均衡主要是解决Web服务器处理能力瓶颈的，而非网络传输能力，很多站点的互联网连接带宽总共也不过10MB，只有极少的站点能够拥有较高速的网络连接，因此一般没有必要使用这些负载均衡器这样的昂贵设备。

   使 用软件方式来实现基于网络地址转换的负载均衡则要实际的多，除了一些厂商提供的解决方法之外，更有效的方法是使用免费的自由软件来完成这项任务。其中包括 Linux Virtual Server Project中的NAT实现方式，或者本文作者在FreeBSD下对natd的修订版本。一般来讲，使用这种软件方式来实现地址转换，中心负载均衡器存 在带宽限制，在100MB的快速以太网条件下，能得到最快达80MB的带宽，然而在实际应用中，可能只有40MB-60MB的可用带宽。

5. 扩展的负载均衡技术

上 面使用网络地址转换来实现负载分担，毫无疑问所有的网络连接都必须通过中心负载均衡器，那么如果负载特别大，以至于后台的服务器数量不再在是几台、十几 台，而是上百台甚至更多，即便是使用性能优秀的硬件交换机也回遇到瓶颈。此时问题将转变为，如何将那么多台服务器分布到各个互联网的多个位置，分散网络负 担。当然这可以通过综合使用DNS和NAT两种方法来实现，然而更好的方式是使用一种半中心的负载均衡方式。

在这种半中心的负载均衡方式下，即当客户请求发送给负载均衡器的时候，中心负载均衡器将请求打包并发送给某个服务器，而服务器的回应请求不再返回给中心负载均衡器，而是直接返回给客户，因此中心负载均衡器只负责接受并转发请求，其网络负担就较小了。

上图来自Linux Virtual Server Project，为他们使用IP隧道实现的这种负载分担能力的请求/回应过程，此时每个后台服务器都需要进行特别的地址转换，以欺骗浏览器客户，认为它的回应为正确的回应。

同样，这种方式的硬件实现方式也非常昂贵，但是会根据厂商的不同，具备不同的特殊功能，例如对SSL的支持等。

由于这种方式比较复杂，因此实现起来比较困难，它的起点也很高，当前情况下网站并不需要这么大的处理能力。

比 较上面的负载均衡方式，DNS最容易，也最常用，能够满足一般的需求。但如果需要进一步的管理和控制，可以选用反向代理方式或NAT方式，这两种之间进行 选择主要依赖缓冲是不是很重要，最大的并发访问数量是多少等条件。而如果网站上对负载影响很厉害的CGI程序是由网站自己开发的，也可以考虑在程序中自己 使用Locaction来支持负载均衡。半中心化的负载分担方式至少在国内当前的情况下还不需要。
http://galaxystar.javaeye.com/blog/50546

这篇短文源于comp.lang.java.programmer跟comp.lang.c++上发生的一场大辩论，支持C++和Java
的两派不同势力展开了新世纪第一场冲突，跟贴发言超过350，两派都有名角压阵。C++阵营的擂主是
Pete Becker，ACM会员，Dinkumware Ltd. 的技术副总监。此君精通C++和Java，开发过两种语言的
核心类库，但是却对C++狂热之极，而对于Java颇不以为然。平时谈到Java的时候还好，一旦有人胆
敢用Java来批判C++，立刻忍不住火爆脾气跳将出来，以坚韧不拔的毅力和大无畏精神与对手周旋，
舌战群儒，哪怕只剩下一个人也要血战到底。这等奇人当真少见！我真奇怪他整天泡在usenet上，
不用工作么？他的老板P.J. Plauger如此宽宏大量？Java阵营主角是一个网名Razzi的兄弟，另外有
Sun公司大名鼎鼎的Peter van der Linden助阵，妙语连珠，寸土必争，加上人多势众，一度占据优势。
C++阵营里大拿虽然很多，但是大多数没有Pete那么多闲工夫，例如Greg Comeau，Comeau公司老板，
每次来个只言片语，实在帮不了Pete多大忙。但是自从C++阵营中冒出一个无名小子，网名Courage(勇气)，
发动对Java GC机制的批判，形势为之一变。C++阵营眼下处于全攻之势，Java阵营疲于防守，只能
招架说：“你们没有证据，没有统计资料”，形势很被动。

垃圾收集(GC)不是一直被Java fans用来炫耀，引以为傲的优点么？怎么成了弱点了？我大惑不解，定睛
一看，才觉得此中颇有道理。

首先，Java Swing库存在大量资源泄漏问题，这一点SUN非常清楚，称之为bugs，正在极力修正。但是看来
这里的问题恐怕不仅是库编写者的疏忽，可能根源在于深层的机制，未必能够轻易解决，搞不好要伤筋动骨。
不过这个问题不是那么根本，C++阵营觉得如果抓住对方的弱点攻击，就算是占了上风也没什么说服力。谁
没有缺点呢？于是反其道而行之，猛烈攻击Java阵营觉得最得意的东西，Java的GC机制本身。

首先来想一想，memory leak到底意味着什么。在C++中，new出来的对象没有delete，这就导致了memory
leak。但是C++早就有了克服这一问题的办法——smart pointer。通过使用标准库里设计精致的auto_ptr
以及各种STL容器，还有例如boost库(差不多是个准标准库了)中的四个smart pointers，C++程序员只要
花上一个星期的时间学习最新的资料，就可以拍着胸脯说：“我写的程序没有memory leak!”。

相比之下，Java似乎更优秀，因为从一开始你就不用考虑什么特殊的机制，大胆地往前new，自有GC替你
收拾残局。Java的GC实际上是JVM中的一个独立线程，采用不同的算法策略来收集heap中那些不再有
reference指向的垃圾对象所占用的内存。但是，通常情况下，GC线程的优先级比较低，只有在当前程序
空闲的时候才会被调度，收集垃圾。当然，如果JVM感到内存紧张了，JVM会主动调用GC来收集垃圾，获取
更多的内存。请注意，Java的GC工作的时机是：1. 当前程序不忙，有空闲时间。2. 空闲内存不足。
现在我们考虑一种常见的情况，程序在紧张运行之中，没哟空闲时间给GC来运行，同时机器内存很大，
JVM也没有感到内存不足，结果是什么？对了，GC形同虚设，得不到调用。于是，内存被不断吞噬，而那些
早已经用不着的垃圾对象仍在在宝贵的内存里睡大觉。例如：

class BadGc {

    public void job1() {
        String garbage = "I am a garbage, and just sleeping in your precious memory, " +
                  "how do you think you can deal with me? Daydreaming! HAHA!!!";
        ....
    }

    public void job2() {...}

    ...
    ...

    public void job1000() {...}

    public static void main(String[] args) {
        bgc = new BadGc();
 bgc.job1();
 bgc.job2();
 ...
 bgc.job1000();
    }
}

运行中，虽然garbage对象在离开job1()之后，就再也没有用了。但是因为程序忙，内存还够用，所以GC得
不到调度，garbage始终不会被回收，直到程序运行到bgc.job1000()时还躺在内存里嘲笑你。没辙吧！

好了，我承认这段程序很傻。但是你不要以为这只是理论上的假设，恰恰相反，大多数实用中的Java程序都有
类似的效应。这就是为什么Java程序狂耗内存，而且好像给它多少内存吃都不够。你花上大笔的银子把内存
从128升到256，再升到512，结果是，一旦执行复杂任务，内存还是被轻易填满，而且多出来的这些内存只是
用来装垃圾，GC还是不给面子地千呼万唤不出来。等到你的内存终于心力交瘁，GC才姗姗来迟，收拾残局。而
且GC工作的方式也很不好评价，一种方法是一旦有机会回收内存，就把所有的垃圾都回收。你可以想象，这要
花很长时间(几百M的垃圾啊！)，如果你这时侯正在压下开炮的按钮，GC却叫了暂定，好了，你等死吧！另一
种方法，得到机会之后，回收一些内存，让JVM感到内存不那么紧张时就收手。结果呢，内存里始终有大批垃
圾，程序始终在半死不活的荡着。最后，GC可以每隔一段时间就运行一次，每次只回收一部分垃圾，这是现在
大部分JVM的方式，结果是内存也浪费了，还动不动暂停几百毫秒。难啊！

反过来看看C++利用smart pointer达成的效果，一旦某对象不再被引用，系统刻不容缓，立刻回收内存。这
通常发生在关键任务完成后的清理(cleanup)时期，不会影响关键任务的实时性，同时，内存里所有的对象
都是有用的，绝对没有垃圾空占内存。怎么样？传统、朴素的C++是不是更胜一筹？

据统计，目前的Java程序运行期间占用的内存通常为对应C++程序的4-20倍。除了其它的原因，上面所说的是一个
非常主要的因素。我们对memory leak如此愤恨，不就是因为它导致大量的内存垃圾得不到清除吗？如果有了
GC之后，垃圾比以前还来势汹汹，那么GC又有什么好处呢？

当然，C++的smart pointer现在会使用的人不多，所以现在的C++程序普遍存在更严重的memory leak问题。
但是，如果我奶奶跟舒马赫比赛车输掉了，你能够埋怨那辆车子么？
http://www.594k.com/java/html/y2007m1/12051/