一、API|关的用?/span>
API|关我的分析中会用到以下三种场景?nbsp;
- Open API?span style="margin: 0px; padding: 0px; line-height: 21px;"> 企业需要将自n数据、能力等作ؓ开发^台向外开放，通常会以rest的方式向外提供，最好的例子是淘宝开攑^台、腾讯公司的QQ开攑^台、微信开攑^台?Open API开攑^台必然涉及到客户应用的接入、API权限的管理、调用次数管理等Q必然会有一个统一的入口进行管理，q正是API|关可以发挥作用的时候?/span>
- 微服务网兟뀂微服务的概忉|早在2012q提出，在Martin Fowler的大力推q下Q微服务?014q后得到了大力发展?在微服务架构中，有一个组件可以说是必不可的Q那是微服务网养I微服务网兛_理了负蝲均衡Q缓存，路由Q访问控Ӟ服务代理Q监控，日志{。API|关在微服务架构中正是以微服务网关的w䆾存在?nbsp;
- API服务理q_。上q的微服务架构对企业来说有可能实施上是困隄Q企业有很多遗留pȝQ要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系l间存在大量的API服务互相调用Q因此需要对pȝ间服务调用进行管理，清晰地看到各pȝ调用关系Q对pȝ间调用进行监控等?API|关可以解决q些问题Q我们可以认为如果没有大规模的实施微服务架构Q那么对企业来说微服务网兛_是企业的API服务理q_?/span>
二、API|关在企业整体架构中的地?/span>
一个企业随着信息pȝ复杂度的提高Q必然出现外部合作伙伴应用、企业自w的公网应用、企业内|应用等Q在架构上应该将q三U应用区别开Q三U应用的安排U别、访问方式也不一栗?因此在我的设计中这三种应用分别用不同的|关q行API理Q分别是QAPI|关QOpenAPI合伙伙伴应用Q、API|关Q内部应用）、API|关Q内部公|应用）?/span>
三、企业中在如何应用API|关
1、对于OpenAPI使用的API|关来说Q一般合作伙伴要以应用的形式接入到OpenAPIq_Q合作伙伴需要到 OpenAPIq_甌应用?因此在OpenAPI|关之外Q需要有一个面向合作伙伴的使用的^台用于合作伙_q就要求OpenAPI|关需要提供APIl这个用户^台进行访问?如下架构:
当然如果是在单的场景下，可能q不需要提供一个面向合作伙伴的门户Q只需要由公司的运营h员直接添加合作伙伴应用id/密钥{，q种情况下也׃需要合作伙伴门户子pȝ?nbsp;
2、对于内|的API|关Q在起到的作用上来说可以认ؓ是微服务|关Q也可以认ؓ是内|的API服务ȝq_?当企业将所有的应用使用微服务的架构理hQ那么API|关pvC微服务网关的作用?而当企业只是系l与pȝ之间的调用用rest api的方式进行访问时使用API|关对调用进行管理，那么API|关起到的就是API服务ȝ的作用?架构参考如下：
3、对于公司内部公|应用（如APP、公司的|站Q，如果理上比较细_在架构上是可能由独立的API|关来处理这部分内部公网应用Q如果想比较单的处理Q也可以是用面向合作伙伴的API|关?如果使用独立的API|关Q有以下的好处：
- 面向合作伙伴和面向公怸体业务的优先U不一P不同的API|关可以做到业务影响的隔R?/span>
- 内部API使用的管理流E和面向合作伙伴的管理流E可能不一栗?/em>
- 内部的API在功能扩展等斚w的需求一般会大于OpenAPI对于功能的要求?/em>
Z以上的分析，如果公司有能力，那么q是分开使用合作伙伴OPEN API|关和内部公|应用网兟?/span>
四、API|关有哪些竞争方?/span>
1?em id="__mceDel" style="margin: 0px; padding: 0px;">对于Open APIq_的API|关Q我分析只能选择API|关作ؓ解决ҎQ业界没有发现比较好的可以用来作为Open APIq_的入口的其他Ҏ?nbsp;
2、对于作为微服务|关的API|关Q业界的选择可以选择的解x案比较多Q也取决于微服务器的实现ҎQ有一些微服务架构的实现方案是不需要微服务|关的?/em>
- Service MeshQ这是新兴的Z无API|关的架构，通过在客L上的代理完成屏蔽|络层的讉KQ这栯到对应用层最的改动Q当前Service Mesh的品还正在开发中Qƈ没有非常成熟可直接应用的产品?发展最q速的产品是Istio?大家密切x相关产品的研发、业务用进展?/em>
- Zduboo架构Q在q个架构中通常是不需要网关的Q是由客L直接讉K服务提供方，由注册中心向客户端返回服务方的地址?/span>
五、API|关解决Ҏ
U有云开源解x案如下：
- Kong kong是基于Nginx+Luaq行二次开发的ҎQ?https://konghq.com/
- Netflix ZuulQzuul是spring cloud的一个推荐组Ӟhttps://github.com/Netflix/zuul
- orange,q个开源程序是国h开发的Q?http://orange.sumory.com/
公有云解x案：
- Amazon API GatewayQhttps://aws.amazon.com/cn/api-gateway/
- 阉K云API|关Qhttps://www.aliyun.com/product/apigateway/
- 腾讯云API|关Q?https://cloud.tencent.com/product/apigateway
自开发解x案：
- ZNginx+Lua+ OpenResty的方案，可以看到Kong,orange都是Zq个Ҏ
- ZNetty、非dIO模型?通过|上搜烦可以看到国内的宜{一些公司是Zq种ҎQ是一U成熟的Ҏ?/span>
- ZNode.js的方案?q种Ҏ是应用了Node.js天生的非d的特性?/span>
- Zjava Servlet的方案?zuulZ的就是这U方案，q种Ҏ的效率不高，q也是zuulL被诟病的原因?/span>
六、企业怎么选择API|关
如果是要选择一Ƒַ有的API|关Q那么需要从以下几个斚w去考虑?nbsp;
1、性能与可用?/span>
如果一旦采用了API|关Q那么API|关׃作ؓ企业应用核心Q因此性能和可用性是必须要求的?/span>
- 从性能上来_需要让|关增加的时间消耗越短越好，个h觉得需?0ms以下?pȝ需要采用非d的IOQ如epollQNIO{。网兛_各种依赖的交互也需要是非阻塞的Q这h能保证整体系l的高可用性，如：Node.js的响应式~程和基于java体现的RxJava和Future?/span>
- |关必须支持集群部vQQ务一台服务器的crash都应该不影响整体pȝ的可用性?/span>
- 多套|关应该支持同一理q_和同一监控中心?如： 一个企业的OpenAPI|关和内部应用的多个pȝ的不同的微服务|关可以在同一监控中心q行监控?/span>
2、可扩展性、可l护?/span>
一ƾ品L不能满生需求的地方Q因此需求思考品在如何q行二次开发和l护Q是否方便公司团队接手维护品?nbsp;
3、需求匹配度
需要评估各API|关在需求上是否能满I如： 如果是OpenAPIq_需要用API|关Q那么需要看API|关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上L考品是否能满要求?如果是微服务|关Q那么要从微服务的运l、监控、管理等斚wL考品是否够强大?/span>
4、是否开源？公司是否有自开发的能力Q?/span>
现有的开源品如kongQzuulQorange都有基础的API|关的核心功能，q些开源品大多离很好的用有一定的距离Q如Q没有提供管理功能的UI界面、监控功能弱，不支持OpenAPIq_Q没有公司运营与q维的功能等?当然开源品能获取源代码，如果公司有比较强的研发能力，能hold住这些开源品，l过二次开发kong、zuul应该q是适应一些公司，不过需求注意以下一些点Q?/span>
- kong是基于ngnix+lua的，从公司的角度比较难于扑ֈ能去l护q种架构产品的h?需求评估当前公司是否有q个能力ȝ护这个品?/span>
- zuul因ؓ架构的原因在高ƈ发的情况下性能不高Q同旉要去Z研究整合开源的适配zuul的监控和理pȝ?/span>
- orange׃没有被大量用，同时是国内个人在开源，在可持箋性和C资源上不够丰富，Z问题后可能不Ҏ扑ֈ人问?/span>
另外kong提供企业版本的API|关Q当然也是基于ngnix+lua的，企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的理、监控等功能?/span>
5、公有云q是U有?/span>
现在的亚马逊、阿里、腾讯云都在提供基础公有云的API|关Q当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满部分用户的定刉求了。另外很多企业因w信息安全的原因Q不能用外|公有网的API|关服务Q这样就只有选择U有云的Ҏ了?nbsp;
在需求上如果Z公有云的API|关只能做到由内部h员ؓ外网人员甌应用Q无法做到定制的合作伙伴门户Q这也不适合于部分企业的需求?nbsp;
如果作ؓ微服务网养I大多数情况下是希望网x务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的API|关才能满需求?nbsp;
l合上面的分析，基础公有云的API|关只有满一部分单客L需求，对于很多企业来说U有云的API|关才是正确的选择?/span>
文章作者介l：
来自于小豹科技的架构师-专注于Y件研发基于^台性Y件的研发Q目前我正在研发一Ƒ֟于Netty、响应式架构的插件式的API|关Q希望能对行业带来一些改变?我希望与对OpenAPI、微服务、API|关、Service Mesh{感兴趣的朋友多交流?有兴的朋友请加我的QQ?44054462?/span>
]]>
]]>
寒蝉凄切。对长亭晚，骤雨初歇。都门帐饮无l，留恋处、兰舟催发。执手相看泪|竟无语凝噎。念d、千里烟波，暮霭沉沉楚天阔?
多情自古伤离别，更那堪冷落清U节Q今宵酒醒何处？杨柳岸、晓风残月。此ȝq_应是良辰好景虚设。便U|千种风情Q更与何Q?/span>
]]>
]]>
do
echo "$line"
done <"$1"
second.sh
while [ "$number" -lt 100 ]
do
echo "$number"
number='expr $number + 1'
done
echo
]]>
Internet的快速增长多媒体网l服务器Q特别是Web服务器，面对的访问者数量快速增加，|络服务器需要具备提供大量ƈ发访问服务的能力?例如Yahoo每天会收到数百万ơ的讉KhQ因此对于提供大负蝲Web服务的服务器来讲QCPU、I/O处理能力很快会成为瓶颈?/p>
单的 提高g性能q不能真正解册个问题，因ؓ单台服务器的性能L有限的，一般来Ԍ一台PC服务器所能提供的q发讉K处理能力大约?000个，更ؓ高档 的专用服务器能够支持3000-5000个ƈ发访问，q样的能力还是无法满载较大的|站的要求。尤其是|络hhH发性，当某些重大事件发生时Q网 l访问就会急剧上升Q从而造成|络瓉Q例如在|上发布的克林顿弹劾书就是很明显的例子。必采用多台服务器提供|络服务Qƈ网l请求分配给q些服务?分担Q才能提供处理大量ƈ发服务的能力?/p>
当用多台服务器来分担负载的时候，最单的办法是将不同的服务器用在不同的方面?按提供的内容q行分割Ӟ可以一台服务器用于提供新闻面Q而另一台用于提供游戏页面；或者可以按服务器的功能q行分割Q将一台服务器用于提供静态页?讉KQ而另一些用于提供CGI{需要大量消耗资源的动态页面访问。然而由于网l访问的H发性，使得很难定那些面造成的负载太大，如果服务的面分割 的过l就会造成很大费。事实上造成负蝲q大的页面常常是在变化中的，如果要经常按照负载变化来调整面所在的服务器，那么势必对管理和l护造成极大的问 题。因此这U分割方法只能是大方向的调整Q对于大负蝲的网站，Ҏ的解军_法还需要应用负载均衡技术?/p>
负蝲均衡的思\下多?服务器ؓ对称方式Q每台服务器都具备等LCQ都可以单独对外提供服务而无d他服务器的辅助。然后通过某种负蝲分担技术，外部发送来的请求均匀分配 到对U结构中的某一台服务器上，而接收到h的服务器都独立回应客h的请求。由于徏立内容完全一致的Web服务器ƈ不复杂，可以使用服务器同步更新或?׃n存储I间{方法来完成Q因此负载均衡技术就成ؓ建立一个高负蝲Web站点的关键性技术?/p>
- Z特定服务器Y件的负蝲均衡
?多网l协议都支持“重定?#8221;功能Q例如在HTTP协议中支持Location指oQ接收到q个指o的浏览器自动重定向到Location指明的另一?URL上。由于发送Location指o比v执行服务hQ对Web服务器的负蝲要小的多Q因此可以根据这个功能来设计一U负载均衡的服务器。Q何时?Web服务器认p载较大的时候，它就不再直接发送回览器请求的|页Q而是送回一个Locaction指oQ让览器去服务器集中的其他服务器?获得所需要的|页?/p>
在这U方式下Q服务器本n必须支持q种功能Q然而具体实现v来却有很多困难，例如一台服务器如何能保证它重定向过的服?器是比较I闲的，q且不会再次发送Location指oQLocation指o和浏览器都没有这斚w的支持能力，q样很容易在览器上形成一U死循环。因 此这U方式实际应用当中ƈ不多见，使用q种方式实现的服务器集群软g也较。有些特定情况下可以使用CGIQ包括用FastCGI或mod_perl?展来改善性能Q来模拟q种方式d担负载，而Web服务器仍然保持简z、高效的Ҏ，此时避免Location循环的Q务将qLCGIE序来承担?/p>
- ZDNS的负载均?/strong>
?于基于服务器软g的负载均衡需要改动YӞ因此常常是得不偿失，负蝲均衡最好是在服务器软g之外来完成，q样才能利用现有服务器Y件的U种优势。最早的?载均衡技术是通过DNS服务中的随机名字解析来实现的Q在DNS服务器中Q可以ؓ多个不同的地址配置同一个名字，而最l查询这个名字的客户机将在解析这?名字时得到其中的一个地址。因此，对于同一个名字，不同的客h会得C同的地址Q他们也p问不同地址上的Web服务器，从而达到负载均衡的目的?/p>
例如如果希望使用三个Web服务器来回应对www.exampleorg.org.cn的HTTPhQ就可以讄该域的DNS服务器中关于该域的数据包括有与下面例子类似的l果Q?/p>
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
此后外部的客h可能随机的得到对应www的不同地址Q那么随后的HTTPh也就发送给不同地址了?/p>
DNS 负蝲均衡的优Ҏ单、易行，q且服务器可以位于互联网的Q意位|上Q当前用在包括Yahoo在内的Web站点上。然而它也存在不缺点，一个缺Ҏ?了保证DNS数据及时更新Q一般都要将DNS的刷新时间设|的较小Q但太小׃造成太大的额外网l流量，q且更改了DNS数据之后也不能立即生效；W二?是DNS负蝲均衡无法得知服务器之间的差异Q它不能做到为性能较好的服务器多分配请求，也不能了解到服务器的当前状态，甚至会出现客戯求集中在某一台服 务器上的偶然情况?/p>
- 反向代理负蝲均衡
使用代理服务器可以将h转发l内部的Web服务器，使用q种加?模式昄可以提升静态网늚讉K速度。因此也可以考虑使用q种技术，让代理服务器请求均匀转发l多台内部Web服务器之一上，从而达到负载均衡的目的?q种代理方式与普通的代理方式有所不同Q标准代理方式是客户使用代理讉K多个外部Web服务器，而这U代理方式是多个客户使用它访问内部Web服务器，?此也被称为反向代理模式?/p>
实现q个反向代理能力q不能算是一个特别复杂的dQ但是在负蝲均衡中要求特别高的效率，q样实现h׃是十?单的了。每针对一ơ代理，代理服务器就必须打开两个q接Q一个ؓ对外的连接，一个ؓ对内的连接，因此对于q接h数量非常大的时候，代理服务器的负蝲?非怹大了Q在最后反向代理服务器会成为服务的瓉。例如，使用Apache的mod_rproxy模块来实现负载均衡功能时Q提供的q发q接数量?Apache本n的ƈ发连接数量的限制。一般来Ԍ可以使用它来对连接数量不是特别大Q但每次q接都需要消耗大量处理资源的站点q行负蝲均衡Q例如搜寅R?/p>
?用反向代理的好处是，可以负载均衡和代理服务器的高速缓存技术结合在一P提供有益的性能Q具备额外的安全性，外部客户不能直接讉K真实的服务器。ƈ?实现h可以实现较好的负载均衡策略，负载可以非常均衡的分给内部服务器，不会出现负蝲集中到某个服务器的偶然现象?/p>
- ZNAT的负载均衡技?/strong>
|?l地址转换为在内部地址和外部地址之间q行转换Q以便具备内部地址的计机能访问外部网l，而当外部|络中的计算问地址转换|关拥有的某一外部地址 Ӟ地址转换|关能将其{发到一个映的内部地址上。因此如果地址转换|关能将每个q接均匀转换Z同的内部服务器地址Q此后外部网l中的计机各自与 自己转换得到的地址上服务器q行通信Q从而达到负载分担的目的?/p>
?址转换可以通过软g方式来实玎ͼ也可以通过g方式来实现。用硬件方式进行操作一般称Z换，而当交换必须保存TCPq接信息的时候，q种针对OSI|?l层的操作就被称为第四层交换。支持负载均衡的|络地址转换为第四层交换机的一U重要功能，׃它基于定制的g芯片Q因此其性能非常优秀Q很多交换机?U具?00MB-800MB的第四层交换能力Q然而也有一些资料表明，在如此快的速度下，大部分交换机׃再具备第四层交换能力了，而仅仅支持第三层?至第二层交换?/p>
然而对于大部分站点来讲Q当前负载均衡主要是解决Web服务器处理能力瓶颈的Q而非|络传输能力Q很多站点的互联|连接带宽d也不q?0MBQ只有极的站点能够拥有较高速的|络q接Q因此一般没有必要用这些负载均衡器q样的昂贵设备?/p>
?用Y件方式来实现Z|络地址转换的负载均衡则要实际的多，除了一些厂商提供的解决Ҏ之外Q更有效的方法是使用免费的自pY件来完成q项d。其中包?Linux Virtual Server Project中的NAT实现方式Q或者本文作者在FreeBSD下对natd的修订版本。一般来Ԍ使用q种软g方式来实现地址转换Q中心负载均衡器?在带宽限Ӟ?00MB的快速以太网条g下，能得到最快达80MB的带宽，然而在实际应用中，可能只有40MB-60MB的可用带宽?/p>
- 扩展的负载均衡技?
- 反向代理负蝲均衡
?面用网l地址转换来实现负载分担，毫无疑问所有的|络q接都必通过中心负蝲均衡器，那么如果负蝲特别大，以至于后台的服务器数量不再在是几台、十?収ͼ而是上百台甚x多，即便是用性能优秀的硬件交换机也回遇到瓉。此旉题将转变为，如何那么多台服务器分布到各个互联网的多个位|，分散|络?担。当然这可以通过l合使用DNS和NAT两种Ҏ来实玎ͼ然而更好的方式是用一U半中心的负载均衡方式?/p>
在这U半中心的负载均衡方式下Q即当客戯求发送给负蝲均衡器的时候，中心负蝲均衡器将h打包q发送给某个服务器，而服务器的回应请求不再返回给中心负蝲均衡器，而是直接q回l客P因此中心负蝲均衡器只负责接受q{发请求，其网l负担就较小了?/p>
上图来自Linux Virtual Server ProjectQؓ他们使用IP隧道实现的这U负载分担能力的h/回应q程Q此时每个后台服务器都需要进行特别的地址转换Q以ƺ骗览器客P认ؓ它的回应为正的回应?/p>
同样Q这U方式的g实现方式也非常昂贵，但是会根据厂商的不同Q具备不同的Ҏ功能Q例如对SSL的支持等?/p>
׃q种方式比较复杂Q因此实现v来比较困难，它的L也很高，当前情况下网站ƈ不需要这么大的处理能力?/font>
?较上面的负蝲均衡方式QDNS最ҎQ也最常用Q能够满一般的需求。但如果需要进一步的理和控Ӟ可以选用反向代理方式或NAT方式Q这两种之间q行 选择主要依赖~冲是不是很重要Q最大的q发讉K数量是多等条g。而如果网站上对负载媄响很厉害的CGIE序是由|站自己开发的Q也可以考虑在程序中自己 使用Locaction来支持负载均衡。半中心化的负蝲分担方式臛_在国内当前的情况下还不需要?br /> http://galaxystar.javaeye.com/blog/50546
]]>
Python, EiffelQC#QRoby{无一例外地都使用了GC机制。但既然Java中的GC最名，所以天?br /> 下来自然应该抗着?/span>
q篇短文源于comp.lang.java.programmer跟comp.lang.c++上发生的一场大辩论Q支持C++和Java
的两z不同势力展开了新世纪W一场冲H，跟脓发言过350Q两zN有名角压cC++阵营的擂L
Pete BeckerQACM会员QDinkumware Ltd. 的技术副ȝ。此君精通C++和JavaQ开发过两种语言?br />
核心cdQ但是却对C++狂热之极Q而对于Java颇不以ؓ然。^时谈到Java的时候还好，一旦有
敢用Java来批判C++Q立d不住火爆脾气跛_出来Q以坚韧不拔的毅力和大无畏精与Ҏ周旋Q?br />
舌战儒Q哪怕只剩下一个h也要血战到底。这{奇人当真少见！我真奇怪他整天泡在usenet上，
不用工作么？他的老板P.J. Plauger如此宽宏大量QJava阵营主角是一个网名Razzi的兄弟，另外?br />
Sun公司大名鼎鼎的Peter van der Linden助阵Q妙语连珠，寸土必争Q加上h多势众，一度占据优ѝ?br />
C++阵营里大拿虽然很多，但是大多数没有Pete那么多闲工夫Q例如Greg ComeauQComeau公司老板Q?br />
每次来个只言片语Q实在帮不了Pete多大忙。但是自从C++阵营中冒Z个无名小子，|名Courage(勇气)Q?br />
发动对Java GC机制的批判，形势Z一变。C++阵营g处于全攻之势QJava阵营疲于防守Q只?br />
招架_“你们没有证据Q没有统计资?#8221;QŞ势很被动?/span>
垃圾攉(GC)不是一直被Java fans用来炫耀Q引以ؓ傲的优点么？怎么成了q了？我大惑不解，定睛
一看，才觉得此中颇有道理?/span>
首先QJava Swing库存在大量资源泄漏问题，q一点SUN非常清楚Q称之ؓbugsQ正在极力修正。但是看?br />
q里的问题恐怕不仅是库编写者的疏忽Q可能根源在于深层的机制Q未必能够轻易解冻I搞不好要伤筋动骨?br />
不过q个问题不是那么ҎQC++阵营觉得如果抓住Ҏ的弱Ҏ击，q是占了上风也没什么说服力。谁
没有~点呢？于是反其道而行之，猛烈dJava阵营觉得最得意的东西，Java的GC机制本n?/span>
首先来想一惻Imemory leak到底意味着什么。在C++中，new出来的对象没有deleteQ这导致了memory
leak。但是C++早就有了克服q一问题的办法——smart pointer。通过使用标准库里设计_致的auto_ptr
以及各种STL容器Q还有例如boost?差不多是个准标准库了)中的四个smart pointersQC++E序员只?br />
׃一个星期的旉学习最新的资料Q就可以拍着胸脯_“我写?/span>E序没有memory leak!”?/span>
相比之下QJavag更优UQ因Z一开始你׃用考虑什么特D的机制Q大胆地往前newQ自有GC替你
收拾D局。Java的GC实际上是JVM中的一个独立线E，采用不同的算?/span>{略来收集heap中那些不再有
reference指向的垃圑֯象所占用的内存。但是，通常情况下，GCU程的优先比较低，只有在当?/span>E序
I闲的时候才会被调度Q收集垃圾。当Ӟ如果JVM感到内存紧张了，JVM会主?/span>调用GC来收集垃圾，获取
更多的内存。请注意QJava的GC工作的时机是Q?. 当前E序不忙Q有I闲旉?. I闲内存不?br />
现在我们考虑一U常见的情况Q?/span>E序在紧张运行之中，没哟I闲旉lGC来运行，同时机器内存很大Q?br />
JVM也没有感到内存不Il果是什么？对了QGC形同虚设Q得不到调用。于是，内存被不断吞噬，而那?br />
早已l用不着的垃圑֯象仍在在宝贵的内存里睡大觉。例如：
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();
}
}
q行中，虽然garbage对象在离开job1()之后Q就再也没有用了。但是因?/span>E序忙，内存q够用，所以GC?br /> 不到调度Qgarbage始终不会被回Ӟ直到E序q行到bgc.job1000()时还w在内存里嘲W你。没辙吧Q?/span>
好了Q我承认q段E序很傻。但是你不要以ؓq只是理Z的假设，恰恰相反Q大多数实用中的JavaE序都有
cM的效应。这是Z么JavaE序狂耗内存，而且好像l它多少内存吃都不够。你׃大笔的银子把内存
?28升到256Q再升到512Q结果是Q一旦执行复杂Q务，内存q是被轻易填满，而且多出来的q些内存只是
用来装垃圾，GCq是不给面子地千g唤不出来。等C的内存终于心力交瘁，GC才姗姗来q，收拾D局。?br />
且GC工作的方式也很不好评P一U方法是一旦有Z回收内存Q就把所有的垃圾都回收。你可以惌Q这?br />
花很长时?几百M的垃圑֕Q?Q如果你q时侯正在压下开炮的按钮QGC却叫了暂定，好了Q你{死吧！另一
U方法，得到Z之后Q回收一些内存，让JVM感到内存不那么紧张时收手。结果呢Q内存里始终有大批垃
圾，E序始终在半Mzȝ荡着。最后，GC可以每隔一D|间就q行一ơ，每次只回收一部分垃圾Q这是现?br />
大部分JVM的方式，l果是内存也费了，q动不动暂停几百毫秒。难啊！
反过来看看C++利用smart pointer达成的效果，一旦某对象不再被引用，pȝM容缓Q立d收内存。这
通常发生在关键Q务完成后的清?cleanup)时期Q不会媄响关键Q务的实时性，同时Q内存里所有的对象
都是有用的，l对没有垃圾I占内存。怎么P传统、朴素的C++是不是更胜一{？
据统计，目前的JavaE序q行期间占用的内存通常为对应C++E序?-20倍。除了其它的原因Q上面所说的是一?br /> 非常主要的因素。我们对memory leak如此愤恨Q不是因ؓ它导致大量的内存垃圾得不到清除吗Q如果有?br /> GC之后Q垃圾比以前q来势v汹，那么GC又有什么好处呢Q?/span>
当然QC++的smart pointer现在会用的Z多，所以现在的C++E序普遍存在更严重的memory leak问题?br /> 但是Q如果我奶奶跟舒马赫比赛车输掉了Q你能够埋怨那辆R子么Q?br /> http://www.594k.com/java/html/y2007m1/12051/
]]>