遇见sharon ’ 的文章存档

为什么选择PaaS?

何为PaaS

地球人都知道PaaS就是Platform as a Service的缩写,但到底什么是PaaS呢?

假如我们现在需要一个业务,提供一个很简单的”hello world”服务,那么需要的资源有哪些呢,看下图:

IaaS&PaaS覆盖图

IaaS&PaaS覆盖图

从最底层的IDC、机房、网络、服务器,到服务器上的操作系统,操作系统上的服务软件(主要包括WebServices、数据库、缓存等),当然最终在WebServices里运行的是我们的业务代码。如果我们生活在互联网的初始阶段,那么这些元素都是需要我们关心的,我们不得不为带宽机架跟运营商打交道,为域名备案跟通管局打交道,为服务器跟服务器供应商打交道,最后还得雇佣管理一个运维团队,帮助维护自己的IT资源。这会使人疯掉!

现在幸福的事情,IaaS(Infrastructure as a Service),来了,IaaS帮我们节省了红线所涉及的部分,包括IDC、网络、服务器、甚至包括部分操作系统,为什么说部分操作系统呢?因为我们还是要关心操作系统挂掉、机器宕机等因素,如果我们不关心,或者说我们从业务的架构上不考虑这些因素,是很难保证业务稳定的。

而PaaS呢?PaaS帮我们节省了蓝色涉及的部分,也就是说除了IaaS节省的部分外,还节省了服务软件和代码的部分,换句话说,PaaS提供了一个完整的业务开发、运行环境,我们无需关心怎么安装Apache、怎么配置缓存、怎么配置数据库读写分离,所有这些已经以服务的方式(注意:不是以机器的方式)提供好了,我们需要做的,只是把业务代码放上来就好了。

总之,IaaS提供的还是虚拟机资源,而PaaS提供的是实际业务的开发、运行环境,正如SAE对自己的定位:“Web应用/业务的分布式开发、运行平台”。

PaaS和IaaS的区别

刚才说了IaaS主要是虚拟机资源,而PaaS提供的是业务的开发、运行环境,那么PaaS和IaaS的区别就是这些吗?

云计算追求的就是通过共享从而降低成本,并且利用技术提供更好的服务。我们来看一个生活中的例子:

我们去饭店吃饭,菜很好吃,但有一个事比较烦心:“到底点多少菜”,点的多了怕浪费,点的少了怕不够吃,快吃完了再点又怕上菜慢,现在我们利用云计算的思路解决这个问题=》

IaaS的办法:将菜“虚拟化”,将一份菜切分为半份菜、1/3份菜,甚至1/4菜,用户可以点小份。

这种办法很有效,可以有效降低我们吃饭的成本,但仍不是特别方便,A,我们无法准确预估需要点多少份;B,吃着吃着饭,突然来了一个朋友,又要现点份菜,这需要上菜时间,耽误工夫。

那么怎么才能做的更好呢?人类吃饭的单位都是一口,没有人能吃“半口饭”,能不能按照口供应呢?我们来看:

PaaS的办法:通过一种技术,将菜按口供应,每个顾客只要张嘴就可以吃菜,不张嘴就不吃了,停止计费,来了一个新朋友,也是通过同样的方式,只要张嘴就有菜吃。

IaaS&PaaS解决问题对比

IaaS&PaaS解决问题对比

这张图可以看出,PaaS对比IaaS虚拟化的粒度更细,更贴近用户的实际需要,因为用户真正需要的并不是虚拟机,而是满足业务运行需求。下面我们来仔细讨论一下PaaS和IaaS的区别吧:

PaaS的计费粒度更细

从计费粒度上,PaaS比IaaS更细,IaaS普遍以 虚拟机的实例数*运行时间 计费,即使IaaS标榜他们的计费单元可以精确到秒级,但如果用户业务某个时间段没有任何请求,用户仍然需要为这部分虚拟机使用时间付费,因为用户无法预知下一次请求什么时候到来,所以用户无法关闭所有虚拟机。

而PaaS是以请求消耗的资源为单元计费的,如SAE价格:

SAE价格列表

SAE价格列表

这样,如果用户的业务暂时没有任何请求,则用户无需支付任何费用,做到了真正的“所付即所用”。

从SAE上用户的实际使用情况来看,几乎所有用户对比之前的使用IaaS时都会有不同程度的成本节约,以某创业为例,日均15万PV,

PaaS比IaaS更可靠

IaaS用户容易高估自己的服务可靠性,这里面有两个原因:
- IaaS服务厂商往往夸大自己的服务可靠性,实际从目前看任何一个IaaS厂商都时不时有重大故障报出来
- IaaS用户迷信厂商提供的SLA,自己不进行高可靠架构部署
我见过在IaaS只用2台虚拟机,然后标榜自己的服务可靠性有多高的用户,殊不知当物理机宕机时,虚拟机一定会收到影响,目前IaaS服务商能提供热迁移的只是少数,即使能提供也是需要提前准备的,无法做到故障时实时切换

PaaS隐藏了服务器、虚拟机的概念,把一切功能服务化,而这些服务都是基于高可靠架构的,以SAE提供的Cron定时服务为例,这套Cron服务是基于分布式环境,任何一台机器宕机都不会影响定时任务的准确触发。

PaaS是真正的“高可扩展”

要明白这个问题,我们先来看什么叫“可扩展”,可扩展有两个层面:
1,用户可以自行扩展资源,通过手工的方式(包括页面点击、API调用等)
2,随着用户的业务扩张,自动扩展

几乎所有的IaaS厂商都可以实现层面1,但层面1的问题是,用户不知道什么时候扩展。用户真正需要的是层面2的扩展,即随着业务增长,资源自动扩展,整个过程用户可以完全不感知,目前这种层面的“高可扩展”没有任何一家IaaS厂商提供。

而SAE恰恰提供这种层面2的高可扩展,SAE会自动判断用户的业务是否存在等待队列,一旦请求出现等待,将自动将请求分配新的计算节点,通过这种机制,用户从PV 100/天涨到PV 1亿/天,可以做到瞬间实现而无需用户做任何操作。

PaaS是免运维的云计算

“免运维”是PaaS的最大魅力,因为用户把代码放上来,就可以完全不管了,无论业务凋零还是业务暴涨,都无需人工干预,当然SAE提供完整的图表展现用户的各种请求曲线,了解业务情况还是必须的。在SAE上的很多用户团队里都是0运维,也就是一个运维人员都没有,这在传统业务团队中是不可想象的。

PaaS的缺点

虽然PaaS有免运维、高可靠、自动扩展、更加节约成本等优点,但是PaaS也有缺点,PaaS的最大缺点就是因为用户无法看见服务器,感受不到虚拟机,这样限制了用户的自主性和灵活性,比如用户想部署一个自己的C程序,或者用户想直接开一个FTP管理文件,这些需求都无法在PaaS中满足,因为PaaS提供的是一个业务的开发、运行环境,而不是用户能够登陆的云主机。

那么既然PaaS有优点也有缺点,那么什么情况适合使用PaaS呢?

PaaS的适用场景

其实,PaaS和IaaS各有各的适用场景,主要由以下一些规律:

非HTTP业务(如游戏服务端、数据分析服务)适合用IaaS,HTTP业务(网站、RESTfulAPI服务端)适合用PaaS;

大型团队(拥有丰富的系统、网络、运维能力和经验)适合用IaaS,创业团队/小型团队(团队规模小,全部聚焦在业务)适合用PaaS;

技术团队(喜欢定制化、喜欢掌控一切)适合用IaaS,产品团队(聚焦在产品开发)适合用PaaS;

资金充裕(能够雇佣昂贵的系统工程师、能够支付没有流量的虚机费用)的团队适合用IaaS,资金紧张(对成本比较care的用户)的适合用PaaS;

PaaS是真正的云计算平台

总之,在桌面时代,我们需要的不是IBM ThinkPad、甚至不是Windows,而是上面成千上万的应用、游戏;到了云时代,我们需要的既不是几core的虚拟机、也不是什么EBS存储,而是一个能让我们的业务稳定可靠省心运行的环境,如果有这样的环境,除了技术Geek,我想没有人想管服务器。。。

PaaS尽管有种种问题,但它确实是从诞生就想提供给用户一个省心、稳定的业务运行环境,用户一旦部署,不需要关心扩容,不需要关心架构,不需要关心宕机,不需要关心配置,不需要关心优化,就可以随着业务的发展时时满足各种需要,所以PaaS是真正的云计算平台。

作者:sae_kobe
原文链接:http://www.jianshu.com/p/5089a8536f97

7个高性能JavaScript代码高亮插件

对于喜欢写技术博客的同学来说,一定对代码高亮组件非常熟悉。一款优秀的JavaScript代码高亮插件,将会帮助你渲染任何一种编程语言,包括一些关键字的着色,以及每行代码的缩进等。今天我们要来分享一些高性能的JavaScript代码高亮插件,这些JavaScript代码高亮插件将非常有效地帮你实现在网页上的代码编辑和展示。

1、SyntaxHighlighter – 最优秀的JavaScript代码高亮插件

SyntaxHighlighter 是一款完全基于JavaScript的代码高亮插件,SyntaxHighlighter 可以对大部分编程语言进行着色渲染,而且代码高亮的性能也非常不错。SyntaxHighlighter 可以自定义主题文件,在初始化的时候指定自己喜欢的主题即可。

r1

 

官方网站:http://alexgorbatchev.com/SyntaxHighlighter/

2、Google Code Prettify – 自由地JavaScript代码高亮插件

Google Code Prettify是一款由Google推出的JavaScript代码高亮插件,Google Code Prettify可以对C/C++, Java, Python, Ruby, PHP, VisualBasic, AWK, Bash, SQL, HTML, XML, CSS, JavaScript, Makefiles和部分Perl编程语言代码高亮着色。

r2

 

官方网站:http://code.google.com/p/google-code-prettify/

3、Highlight.js – 多风格JavaScript代码高亮插件

highlight.js是一个用于在任何web页面上高亮着色显示各种示例源代码语法的JavaScript项目。具有以下特色:

  • 支持 92 种语言,49 种代码格式化风格。
  • 自动检测语言种类
  • 支持多语言混合的代码高亮
  • 支持Node.js
  • 支持使用任何HTML标记
  • 兼容任意js框架

Highlight
阅读全文

修复bug的12个关键步骤

boss:那么,你需要多长时间来修复这个bug?

没有经验的程序员:给我一个小时?最多两个小时?我能马上搞定它!

有经验的程序员:这么说吧,钓到一条鱼要多久我就要多久?!

要多少时间才能修复bug,事先是很难知道的,特别是如果你和这些代码还素不相识的话,情况就更加扑朔迷离了。James Shore在《The Art of Agile 》一书中,明确指出要想修复问题得先知道问题的所在。而我们之所以无法准确估计时间是因为我们不知道需要多久才能发现症结的所在,只有清楚这一点,我们才能合理估计修复bug所需要花费的时间。不过,这个时候恐怕黄花菜都凉了。 Steve McConnell曾说过:

“发现问题—理解问题—这就是程序员90%的工作。”

很多bug都只需改动某一行代码即可。但是需要投入大量时间的是,后面还得指出怎么样才是正确的——就像我们在钓鱼的时候,得知道往哪里下诱饵,什么时候鱼儿容易上钩等等。话说bug有四种类型:第一种易寻易修复,第二种难寻易修复,第三种易寻难修复,第四种难寻难修复。最悲剧的就是最后一型的,不但“寻寻觅觅,凄凄凉凉戚戚”,哪怕终于千辛万苦滴水穿石,也只能在那边不由自主地抓耳挠腮,无奈叹一句“路漫漫其修远兮”。可以这么说,除非是新鲜出炉的代码,不然让你找bug就跟瞎子摸象一样——糊里糊涂,不知道归属于哪种bug类型。

ccc

 

查找和修复bug

你知道“查找和修复bug”意味着什么吗?没错,就是调试!不断的调试,无数次的调试!Paul Butcher通过大量工作,总结出以下结构化的步骤:

1.明确目的。仔细查阅异常报告,确定是否是个bug,找出各种有用的信息发现问题的症结,予以重现。再次检查是否与报告发生重复。如果发生重复,那看看曾经的相关人员是如何处理的。

2.准备工作——找出正确的代码,用排除法清理工作区域。

3.匹配测试环境。如果客户正在操作计算机配置,那么此过程可以跳跃。

4.明确代码的用途,确保现有测试工具一切正常。

5.好了,现在可以出发钓鱼去咯——重现和诊断错误。如果你不能做到重现,那你就不能证明你已经完成修复工作。

6.编写测试案例,或者通过现成的测试案例来捕获bug。

7.进入修复模式——请务必确保不会影响到其他任何部分。但是,在开展修复工作之前,可能你还要包揽重构工作,因为只有这样,你才能无所顾忌地捣鼓代码。而且事后回归测试,还能确保你不会加入任何新的bug。

8.整理代码。通过一步一步重构,让你的代码更易于理解,更安全。

9.找别人来审查一下,当局者迷旁观者清。

10.再次检查此修复过程。

11.试着不从主线出发,以检查这些bug是否会影响其他支线。合并这些变化,处理代码中的差异,回顾所有的审查和测试等工作。

12.思考。好好想一想哪里错了以及为什么错了?为什么你的修复会起效?这种类型的bug还会出现在哪里?在《 The Pragmatic Programmer》一书中,Andy Hunt 和Dave Thomas也如是指出“如果一个bug需要耗费你很多时间,那么一定要好好弄清楚原因”。此外,还需要思考的是,怎么做才能吸取经验教训,将来在类似的问题上不再栽跟头?以及,我们采用的方法、使用的工具是否还有可以改进的地方?以及这些bug的影响和严重程度。

 找到bug,还是修复bug,哪个需要更多时间?

或许建立一个测试环境、重现问题和测试bug所需的时间,要远远多于找到bug和修复bug的时间。不过对于一小部分显而易见的bug,找到它们很简单——不过修复起来可能就不尽如人意了。
阅读全文

Instagram工程师教你如何改善App的性能

【编者按】扁平化设计由于其简洁的外表,更少的按钮和选项使得界面干净整齐,从而减少认知障碍的产生。扁平化设计更是功能上的简化于与重组,相比于拟物化而言,扁平风格的一个优势就在于它可以更加简单直接的将信息和事物的工作方式展示出来。本文来自Instagram一名工程师的分享。

以下为译文:

扁平化设计仅仅只是一个漂亮的外表,还是一个性能利器,从而触发一场UI革命?实践证明是后者。

Tyler Kieft 是Instagram一名工程师,他详细解释了这其中的缘由,更详细的内容请关注他在@scale会议上的演讲: 标准安卓手机上的Instagram 。这个演讲是由Facebook提供的,是“如何在实际情况下设计移动应用程序”系列的一部分,这里的“实际情况”是指那些手机速度更慢、屏幕更小、网络比美国更慢的地方。

为标准手机设计App和高端手机并不一样,Instagram团队需要重新思考他们的设计。从Tyler的谈话中得到的启示之一是转变到扁平化设计,因为这将让应用程序更美观、更实用、并且还能大大提高性能。

这的确出乎我的意料,我曾经认为扁平化设计只是构建更美观的UI。现在想想真是愚蠢之极。感谢Tyler如此详细的解释了扁平化设计的好处, Instagram说明了一切。

扁平化设计是反拟物化,它采用简单的元素、简单的排版、单调的颜色以及简单的设计。

使用扁平化设计,Instagram可以减少120 ms的冷启动时间,同时应用程序更美观、更好用、并且更专注将内容传送到不同大小的手机上。
阅读全文

5种你未必知道的JavaScript和CSS交互的方法

随着浏览器不断的升级改进,CSS和JavaScript之间的界限越来越模糊。本来它们是负责着完全不同的功能,但最终,它们都属于网页前端技术,它们需要相互密切的合作。我们的网页中都有.js文件和.css文件,但这并不意味着CSS和js是独立不能交互的。下面要讲的这五种JavaScript和CSS共同合作的方法你也许未必知道!

用JavaScript获取伪元素(pseudo-element)属性

大家都知道如何通过一个元素的style属性获取它的CSS样式值,但能获取伪元素(pseudo-element)的属性值吗?可以的,使用JavaScript也可以访问页面中的伪元素。

// Get the color value of .element:before
var color = window.getComputedStyle(
	document.querySelector('.element'), ':before'
).getPropertyValue('color');

// Get the content value of .element:before
var content = window.getComputedStyle(
	document.querySelector('.element'), ':before'
).getPropertyValue('content');

看见了吗,我能访问伪元素里的content属性值。如果你想创建一个动态的,风格别致的网站,这是一种非常有用的技术!
阅读全文

机器学习常见算法分类汇总

机器学习无疑是当前数据分析领域的一个热点内容。很多人在平时的工作中都或多或少会用到机器学习的算法。本文为您总结一下常见的机器学习算法,以供您在工作和学习中参考。

机器学习的算法很多。很多时候困惑人们都是,很多算法是一类算法,而有些算法又是从其他算法中延伸出来的。这里,我们从两个方面来给大家介绍,第一个方面是学习的方式,第二个方面是算法的类似性。

学习方式

根据数据类型的不同,对一个问题的建模有不同的方式。在机器学习或者人工智能领域,人们首先会考虑算法的学习方式。在机器学习领域,有几种主要的学习方式。将算法按照学习方式分类是一个不错的想法,这样可以让人们在建模和算法选择的时候考虑能根据输入数据来选择最合适的算法来获得最好的结果。

监督式学习:

b1

 

在监督式学习下,输入数据被称为“训练数据”,每组训练数据有一个明确的标识或结果,如对防垃圾邮件系统中“垃圾邮件”“非垃圾邮件”,对手写数字识别中的“1“,”2“,”3“,”4“等。在建立预测模型的时候,监督式学习建立一个学习过程,将预测结果与“训练数据”的实际结果进行比较,不断的调整预测模型,直到模型的预测结果达到一个预期的准确率。监督式学习的常见应用场景如分类问题和回归问题。常见算法有逻辑回归(Logistic Regression)和反向传递神经网络(Back Propagation Neural Network)

非监督式学习:

b2

 

在非监督式学习中,数据并不被特别标识,学习模型是为了推断出数据的一些内在结构。常见的应用场景包括关联规则的学习以及聚类等。常见算法包括Apriori算法以及k-Means算法。

半监督式学习:

b3

 

在此学习方式下,输入数据部分被标识,部分没有被标识,这种学习模型可以用来进行预测,但是模型首先需要学习数据的内在结构以便合理的组织数据来进行预测。应用场景包括分类和回归,算法包括一些对常用监督式学习算法的延伸,这些算法首先试图对未标识数据进行建模,在此基础上再对标识的数据进行预测。如图论推理算法(Graph Inference)或者拉普拉斯支持向量机(Laplacian SVM.)等。

强化学习:

b4
阅读全文

大型网站系统架构演化之路

前言

一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索、下单、支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段可以广泛运行在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。

一、最开始的网站架构

最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:

LLL

 

二、应用、数据、文件分离

随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。

M1
阅读全文

Web开发者必备的11个精华版JavaScript工具

b1

 

JavaScript正逐步占领互联网,而它的开发工具也百花齐放,难以挑选。这里的11款新兴工具,满足你用JavaScript构建现代网站的各种要求。他们接口简洁,功能强大。这些经过改进与重构的工具会让我们写得少做得多。

1、Meteor

Meteor框架是由其七原则支撑着的。其中某些很战略,例如说要懂得整合开源插件,所以Meteor是已经有成熟的插件的。

c1

 

另外一些就比较战术了:设计简单的API,网络只用来传数据,所有地方都用同一种语言。而“用同一种语言”的意思是,用Node.js和MongoDB,使代码在服务端和客户端都能运行。图中就是在客户端构建一个集合,这些代码同样能运行在后端跟MongoDB交互,实现持久化。

2、Epoch

b2

 

现在流行数据可视化。各种工具以各种方式实现数据可视化,但依然比不上d3.js。而Epoch的创始人另辟蹊径,直接拿d3.js来用,并加入管道来使视图平滑和持续。它使你可以轻松地做出实时的数据可视化。图中展示的是一个实时向左滚动的直方图。

3、Web Starter Kit

b3

 

这个Google出品的工具是一个帮助开发者做出自适应网页的工具,你只需勾画出大概样子,该框架就帮你实现自适应。当然它的实现细节是按Google团队的审美的。

4、Reveal.js

b4

 

它是基于HTML5的,可用来替代PowerPoint。它的强大之处是有各种演示策略,适合用来讲故事或者演说。图中是页面切换的展示。

5、RxJS

b5

 

静态网页已经远去,普通的动态网页也不再新鲜,现在的潮流是是网页更具反应力,就像自动补全。无需等用户点击“搜索”,RxJS就能猜到用户想找什么并呈现出来。图示是一个绑定了维基API的事件。

6、NodeBB

b6

 

NodeBB使得搭建论坛变得简单,它是响应式和可制定的,并且是实时的。现在它加入了一些现代的主题,以及支持小屏幕,无限滚动。图示是NodeBB社区中提供的插件。

7、GulpJS

b7

 

曾几何时人们要重头写HTML、CSS和JS,但现在GilpJS包办一切。你只需写少少JavaScript指定路径,Gulp就会干完剩下的活。就如Ant和Maven之于Java,但Gulp使用JavaScript而不是XML。

8、AngularJS

b8

 

这是来自Google的一个平滑的、轻量的框架。它是MVC的,且是自适应的。

9、Odyssey

b9

 

网页中使用地图,从未如此简单!而且还能像讲故事一样写代码。这就是Odyssey

10、PlayCanvas

b10

 

理论上,做游戏都被当做不正经的。但实际上,就有人用WebGL来做出了PlayCanvas这样的游戏引擎。它包含物理效果、光影、声音。如同现实。

11、Deb.js

b11

 

这个只有1.5KB的Deb.js,轻巧且清晰的js调试工具,比肩Firebug和Chrome的内置调试器!

英文:NetWorkWorld,译者:dncszp

10个对开发项目有害的编程习惯

避免这些常见的编码习惯,会让我们的工作更轻松、软件更安全且更易于扩展。

帕雷托法则明确指出,20%的因导致80%的果。又称为80-20法则,它适用于几乎每一个需要人作为劳动主体的相关领域。

在软件开发领域,这个法则可以概括为,大多数的问题都是由少数不良编码习惯造成的。改变这些习惯,你会更有效率。

下面讲讲最要不得的10条编码习惯:

b1

 

1.拼写错误

让我特别讶异的是,为什么大家明知这个习惯百害而无一利,竟然还是任其在代码中肆虐横行,以致于经常出现拼写错误的变量名和函数名。更加悲剧的是,错误的拼写常常隐蔽得很好,很难发现。

至于解决方法,可以在一个良好的集成开发环境(IDE)上写代码,或者干脆用程序员专用的文本编辑器,这些都可以显著减少拼写错误。还可以选择特定的变量名和函数名,一方面容易拼写,另一方面即便写错了也能轻易发现。尽量避免使用很容易拼错的单词,例如“receive”,很容易拼写成“recieve”。

2.未按规定格式写代码

缩进和格式化,能让我们的代码一目了然、易于理解,有什么错误也能一览无余。而且也方便别人理解和维护。
阅读全文

关于Java的10个谎言

下面的这些都算是比较高级的问题了,面试中一般也很少问到,因为它们可能会把面试者拒之门外。不过你可以自己找个时间来实践一下。

System.exit(0)会跳过finally块的执行

System.setSecurityManager(new SecurityManager() {
        @Override
        public void checkExit(int status) {
            throw new ThreadDeath();
        }
    });
    try {
        System.exit(0);
    } finally {
        System.out.println("In the finally block");
    }

这段代码为什么会输出In the finally block?为什么没有打印出堆栈跟踪信息呢? 2. String str = “Hello”;其中str是一个字符串对象 跟C++不同的是,Java里的变量要么是基础类型,要么是引用。变量不可能是对象。这意味着像这样的表达式:

String str = "Hello";
    String text = "Bye";
    str == text; // 比较两个引用,而不是内容
    str = text; // 把text的引用赋值给str

大多数情况下其实没有太大的区别,不过这么写容易引起困惑。

final StringBuilder sb = new StringBuidler();
    sb.append("Hello"); // 这个引用是final类型的,而不是这个实例。
    method(sb); // 可以通过方法来修改这个实例,不过这个变量是无法修改的
  • Java的内存泄露跟C++程序员理解的一样 内存泄露在维基百科上的定义是”在计算机科学中,如果程序没有正确地管理好内存分配 ,就会出现内存泄露。在面向对象编程中,如果内存中的一个对象无法在代码中访问不到的话,这就是内存泄露。” 不过在Java中,对象总是可达的,那些没有强引用的对象会被清除掉。内存泄露这个术语在Java中意味着:内存中存在着不该存在的对象,通常来说是有些不再使用的资源却仍存储在集合中。

阅读全文