关于CPU，寄存器，内存和多线程
传统的CPU在某一时间只能处理一个指令序列，通常我们把它称为一个线程。在线程处理的过程中CPU的处理单元需要不断调入指令与数据进行处理。随着 CPU技术的发展，CPU的主频与性能不断提高，需要调入指令和数据的速度不断提高。但不幸的是内存技术的发展并没有跟上CPU发展的速度，内存通常无法提供足够的指令和数据给CPU进行处理。
为了解决这个问题，业界通常采用多级缓存的方式。CPU处理单元中的寄存器是最快的，通常一个CPU中有一、两百个寄存器，它可以在一个时钟周期内提供指令和数据。其次是一级缓存，他的大小通常为几十KB，它需要几个时钟周期的访问时间。再下面是二级缓存，他的大小通常为几MB，它需要十几个时钟周期的访问时间。然后是内存，从内存中取得数据需要几十个个时钟周期。而最慢的是硬盘，通常需要几千甚至几万个时钟周期的访问时间。
当CPU需要处理下一条指令时，他通常按照寄存器、一级缓存、二级缓存、内存、硬盘这一顺序去查找。但如果在内存中仍然找不到需要的指令或数据时。系统会进行Context Switch，终止此线程在CPU上的运行，使其处于等待状态，而让其他的线程运行，当此线程需要的数据被调入内存后，此线程处于就绪状态，可以被调度到 CPU上运行。线程间的Context Switch需要几十个时钟周期。
由此可见当CPU需要从内存中取数据时，处理单元需要空转几十个时钟周期，有关统计显示当前CPU处理单元的平均利用率不足25%。为了提高CPU处理单元的利用率，设计者采用了线程级的并行技术，即在CPU的核心中执行一个以上的指令序列。对于操作系统来说，一个物理的处理器相当于两个逻辑的处理器，当前有三种不同的方式，实现多线程技术。
粗粒度的多线程，在任一时刻只有一个线程执行，当线程遇到一个长延迟事件时，如二级缓存不命中，则系统调度另一个线程执行，而不是让系统资源空转等待此线程。这一机制可以提高整个系统的利用率。这两个线程共享许多系统资源，如CPU的寄存器和缓存等，因此这两个线程的切换比Context Switch要快得多，只需要几个时钟周期。IBM在使用PowerPC RS64 IV处理器的pSeries 680和pSeries 660-6M1上使用过这种粗粒度的多线程技术。
另一种与粗粒度的多线程技术相对的是细粒度多线程技术，采用这种多线程的系统循环的执行两个线程的指令，这就需要在处理器的设计上增加许多冗余的部件。如果一个线程遇到个长延迟事件时，对应这一线程执行的时钟周期仍然没有被利用。
第三种多线程技术是同步多线程技术(SMT)，与其他的多线程技术一样，同步多线程能够从多个线程中取出指令来运行，它能够同时执行不同线程的指令。通过同步多线程技术，系统能够动态调整系统环境，如有可能同时执行不同线程的指令。当一个线程遇到长延迟事件时，允许另一个线程使用所用的处理单元。
parameter 和 argument
parameter 中文多翻译为形参，在函数声明的时候定义的，比如：
int abc(int d,int e);//此时d和e 就是parameter
argument就是实参，是在调用这个函数时传递给函数的相匹配的参数。比如：
int h=abc(23,32);//23和32就是argument
REST
概述
REST是英文Representational State Transfer的缩写，中文翻译：表述性状态转移。
他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。
REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。
基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规范的基础上增加新的规范， 就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。
传统的Web应用大都是B/S架构，它包括了如下一些规范：
1. 客户－服务器
这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。
2. 无状态性
无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。
3.缓存
为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。
B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST。
REST在原有的架构上增加了三个新规范：统一接口，分层系统和按需代码。
1.统一接口
REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。
2.分层系统
分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。
3.按需代码
REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。
REST的设计准则
REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则：
1. 网络上的所有事物都被抽象为资源（resource）；
2. 每个资源对应一个唯一的资源标识符（resource identifier）；
3.通过通用的连接器接口（generic connector interface）对资源进行操作；
4. 对资源的各种操作不会改变资源标识符；
5. 所有的操作都是无状态的（stateless）。
REST中的资源所指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10为会员”在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式,txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。
REST是基于Http协议的，任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和 POST方法，对其他方法很少使用，这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。他不仅仅能对互联网资源进行唯一定位，而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内： GET, POST,PUT和DELETE，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，执行这些操作的时候URI是没有变化的，这和以往的 Web开发有很大的区别。正由于这一点，极大的简化了Web开发，也使得URI可以被设计成更为直观的反映资源的结构，这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式：通过URL来设计系统结构。当然了，这种设计方式对一些特定情况也是不适用的，也就是说不是所有的URI都可以RESTful的。
REST 之所以可以提高系统的可伸缩性，就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束，做分布式和集群的时候就更为简单，也可以让系统更为有效的利用缓冲池(Pool）。并且由于服务器端不需要记录客户端的一系列访问，也减少了服务器端的性能。
使用REST架构
对于开发人员来说，关心的是如何使用REST架构，这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构，它带来的更是一种全新的Web开发过程中的思维方式：通过URL来设计系统结构。在REST中，所有的URL都对应着资源，只要URL的设计是良好的，那么其呈现的系统结构也就是良好的。这点和 TDD (Test Driven Development)很相似，他是通过测试用例来设计系统的接口，每一个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能，而只需要把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URL设计系统结构的方式类似，我们只需要根据需求设计出合理地URL，这些 URL不一定非要链接到指定的页面或者完成一些行为，只要它们能够直观的表现出系统的用户接口。根据这些URL，我们就可以方便的设计系统结构。从 REST架构的概念上来看，所有能够被抽象成资源的东西都可以被指定为一个URL，而开发人员所需要做的工作就是如何能把用户需求抽象为资源，以及如何抽象的精确。因为对资源抽象的越为精确，对REST的应用来说就越好。这个和传统MVC开发模式中基于Action的思想差别就非常大。设计良好的URL，不但对于开发人员来说可以更明确的认识系统结构，对使用者来说也方便记忆和识别资源，因为URL足够简单和有意义。按照以往的设计模式，很多URL后面都是一堆参数，对于使用者来说也是很不方便的。
既然REST这么好用，那么是不是所有的Web应用都能采取此种架构呢？答案是否定的。我们知道，直到现在为止，MVC(Model-View- Controller) 模式依然是Web开发最普遍的模式，绝大多数的公司和开发人员都采取此种架构来开发Web应用，并且其思维方式也停留于此。MVC模式由数据，视图和控制器构成，通过事件(Event)触发Controller来改变Model和View。加上Webwork,Struts等开源框架的加入，MVC开发模式已经相当成熟，其思想根本就是基于Action来驱动。从开发人员角度上来说，贸然接受一个新的架构会带来风险，其中的不确定因素太多。并且REST新的思维方式是把所有用户需求抽象为资源，这在实际开发中是比较难做到的，因为并不是所有的用户需求都能被抽象为资源，这样也就是说不是整个系统的结构都能通过REST的来表现。所以在开发中，我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC，因为这适合绝大多数的Web应用开发，开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式，而对其它需求采取MVC开发即可。这里需要提到的就是ROR(Ruby on Rails)框架，这是一个基于Ruby语言的越来越流行的Web开发框架，它极大的提高了Web开发的速度。更为重要的是，ROR(从1.2版本起)框架是第一个引入REST做为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的 REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好的构建Web应用。
对开发人员来说，REST不仅仅在Web开发上贡献了自己的力量，同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上。
面向对象技术具有三个基本的特性
1.封装
在程序设计中，封装是指将一个数据和与这个数据有关的操作集合在一起，形成一个能动的实体——对象，用户不必知道对象行为的实现细节，只需根据对象提供的外部接口访问对象即可。因此，从用户的观点来看，这些对象的行为就像包含在一个“黑匣子”里，是隐蔽的、看不见的。
封装有两个基本前提：一是对象必须是完备的，即必须能够表示整个概念，描述整个问题的各个方面；二是私有性。大多数对象都需要对其内部的数据和过程限制处理权限。私有性不但可以保证对对象的正确操作，而且有利于查错，使一些对象的成员函数私有化，减少它们被处理的机会，于是在追踪时许多地方都可以不必去查。
封装不是面向对象语言所独有的特性，但这种在单一实体中把数据结构和行为捆绑在一起的能力，使封装比传统的把数据结构和行为分离的语言更加清晰、更强有力。
2.继承
继承表明类之间的关系。类不仅仅说明一组对象上的约束，还说明与其他类之间的关系。两个类型可以有共同的特性和行为，但是，一个类型可能包括比另一个类型更多的特性，也可以处理更多的消息。继承表示了基类和派生类之间的相似性。一个基类具有所有由它派生出来的类所共有的特性和行为，而派生类则通过继承重用了基类的特性和行为。
抽象基类提供了公共接口，当希望通过公共接口操作一组(派生)类时就创建抽象基类。
3.多态
多态的含义是相同的行为（在基类中定义）在不同的类中有着不同的实现（在子类中实现），或者更彻底的说，多态性就是以相同的指令唤起不同的函数。
当处理类型层次结构时，程序员常常希望不把对象看作是某一特殊类型的成员，而把它看作基本类型的成员，这样就可以编写不依耐于特殊类型的代码，在添加新的子类后也不影响原来的代码，这是扩展面向对象程序以处理新情况的最普通的方法——通过派生新的子类来扩展程序功能，这个能力极大地减少了软件维护的花费（所谓“软件危机”正是由软件的实际花费远远超出人们的想象而产生的）。
面向对象编程基本原则
单一职责原则（SRP）：
– 一个类应该仅有一个引起它变化的原因。
开放封闭原则（OCP）：
– 类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）
Liskov 替换原则（LSP）:
– 子类必须能够替换它们的基类
依赖倒置原则（DIP）：
– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
接口隔离原则（ISP）：
– 不应该强迫客户程序依赖于它们不用的方法。
《Don't Make Me Think》中的故事
在瑞士日内瓦湖边，有一个隧道，隧道很长，开车穿过隧道需要把车大灯打开。在隧道的出口，是一个观景台，从这里看去，日内瓦湖的美景一览无余。于是，很多游客纷纷在这里下车观赏美景，却忘记了关掉车灯。车灯就这样一直开着，以至于车子没有电了，无法启动，游客们开始怨声载道。有人开始向旅游部门投诉：“进隧道的时候提醒我们开车灯，出隧道的时候不提醒我们关车灯。偏偏在隧道口又是这么美的景色，害得车子没电了，发动不了。”
旅游部门于是考虑在隧道出口设一个提示牌。提示牌的内容如果写“请您关灯”，那么要是晚上，出了隧道也需要开灯，不能关灯，所以不合适。如果写成“白天，出隧道时请您关灯；晚上，请您开灯”，又太罗嗦，车上的还没来得及看清楚，车早开过去了。最后，有人提议写成“您的灯开着了吗？”这样使对方对车灯的状态进行思考，各种情况都包括了，而且言简意赅。
OOA OOD OOP
"工程師修了一條隧道,隧道的一端就是美麗的風景,很多人會開車通過隧道.雖然隧道內已經有燈了,但是設計者擔心隧道可能會停電,所以在隧道的入口立了牌子,提醒駕駛員進入隧道前開燈.可是由此却使得駕駛員由於看到美麗的風景而忘記關燈的情況的發生."
OOA是Object-Oriented Analysis(面向对象分析)
分析师拿到了政府，民众，组织，社团等的需求，这里泛指所有来自客户的需求了；了解需求，分析需求，分析技术实现等，得出一个结论：要在这里修条隧道；于是分析师，系统分析师，架构设计师出现了，他们干的工作就分析出来一个方案，即项目需求吧，他们的身份就是OOA了。
OOD是Object Oriented Design(面向对象设计)
分析师们分析结果出来后，形成了最早的需求模型；可能是一个草图，一张可行性分析XX报告；设计师们拿到这个模型进行细化，模块化，定义所有的细节，也就是详图，或是详细的需求分析规格书了，在这里，可能会有隧道的位置，长度，宽度，高度，容量，光线，材料，设备，电子眼，安全等，这里就是具体的需求文档了。设计师的设计工作完成了，他们就是OOD。
OOP是Object Oriented Programming (面象对象程序设计)
OOP就是施工队了，他们按照设计图的要求完成隧道工程，包括质量，容量，安全等测试，也就是完成项目的实际操作部分，在项目里就是coding的工作和testing的工作。到此为止，隧道就完成了，駕駛員也可以说成是testing的一员，他们进行体验，体验完了，没问题，oop的工作也就结束了，我们可以收工了。
Google让我们越变越傻？ 专注与沉思能力被粉碎
《大西洋月刊》刊文剖析互联网一代大脑退化历程，认为新阅读风格使人退回中世纪
“戴夫，停下。停下好吗？停下，戴夫。你能停下吗，戴夫？”
这个著名的场景出现在库布里克的电影《2001：太空漫游》的片尾，乃超级电脑HAL恳求宇航员戴夫·鲍曼手下留情，放他一条生路。由于电脑故障，戴夫被送入茫茫外空，前路未卜，目的地不明，只好“视死如不归”。最后，他对HAL下了手，平静而冷酷地切断了它的内存（记忆体）电路。
“戴夫，我的思想要没了。”HAL绝望地说。“我感觉得到。我感觉得到。”
网络粉碎专注与沉思的能力
当尼古拉斯·卡尔想起HAL的哀号，不由得脸皮有些酥麻，手脚略感冰凉。“我也感觉得到。”他说。
卡尔在2008年7～8月号的《大西洋月刊》撰文，以《Google是否让我们越变越傻》为题，痛苦地剖析自己和互联网一代的大脑退化历程。“过去几年来，我老有一种不祥之感，觉得有什么人，或什么东西，一直在我脑袋里捣鼓个不停，重绘我的‘脑电图’，重写我的‘脑内存’。”他写道。“我的思想倒没跑掉 ——到目前为止我还能这么说，但它正在改变。”
他注意到，过去读一本书或一篇长文章时，总是不费什么劲儿，脑袋瓜子就专注地跟着其中的叙述或论点，转个没完。可如今这都不灵了。“现在，往往读过了两三页，我的注意力就漂走了。”
卡尔找到了原因。过去这十多年来，他在网上花了好多时间，在互联网的信息汪洋中冲浪、搜寻。对作家而言，网络就像个天上掉下来的聚宝盆，过去要在书堆里花上好几天做的研究，现在几分钟就齐活。Google几下，动两下鼠标，一切就都有了。“对我来说，”卡尔写道，“对别人也是如此，网络正在变成一种万有媒介，一种管道，经由它，信息流过我的眼、耳，进入我的思想。”
信息太丰富了，我们受用不尽，也不忘感恩戴德，却往往忽视了要付出的代价。“网络似乎粉碎了我专注与沉思的能力。现如今，我的脑袋就盼着以网络提供信息的方式来获取信息：飞快的微粒运动。”
网络新阅读方式：海量浏览
卡尔不是唯一一个遇到此种问题的人。长期在密歇根医学院任教的布鲁斯·弗里德曼，今年早些时候也在自己的blog上写到互联网如何改变了他的思维习惯。 “现在我已几乎完全丧失了阅读稍长些文章的能力，不管是在网上，还是在纸上。”他在电话里告诉卡尔，他的思维呈现出一种“碎读”特性，源自上网快速浏览多方短文的习惯。“我再也读不了《战争与和平》了。”弗里德曼承认，“我失去了这个本事。即便是一篇blog，哪怕超过了三四段，也难以下咽。我瞅一眼就跑。”
伦敦大学学院以5年时间做了一个网络研读习惯的研究。学者们以两个学术网站为对象——它们均提供电子期刊、电子书及其他文字信息的在线阅读，分析它们的浏览记录，结果发现，读者总是忙于一篇又一篇地浏览，且极少回看已经访问过的文章。他们打开一篇文章或一本书，通常读上一两页，便“蹦”到另一个地方去了。报告说：“很明显，用户们不是在以传统方式进行在线阅读，相反，一种新‘阅读’方式的迹象已经出现：用户们在标题、内容页和摘要之间进行着一视同仁的‘海量浏览’，以求快速得到结果。这几乎可被视为：他们上网正是为了回避传统意义上的阅读。”
打字机让尼采的写作风格发生变化
互联网改变的不仅是我们的阅读方式，或许还有我们的思维方式，甚至我们的自我。塔夫茨大学的心理学家、《普鲁斯特与鱿鱼：阅读思维的科学与故事》一书作者玛雅妮·沃尔夫说：“我们并非只由阅读的内容定义，我们也被我们阅读的方式所定义。”她担心，将“效率”和“直接”置于一切之上的新阅读风格，或会减低我们进行深度阅读的能力。几百年前的印刷术，令阅读长且复杂的作品成为家常之事，如今的互联网技术莫非使它退回了又短又简单的中世纪？沃尔夫说，上网阅读时，我们充其量只是一台“信息解码器”，而我们专注地进行深度阅读时所形成的那种理解文本的能力、那种丰富的精神联想(企业库 论坛)，在很大程度上都流失掉了。
沃尔夫认为，阅读并非人类与生俱来的技巧，不像说话那样融于我们的基因。我们得训练自己的大脑，让它学会如何将我们所看到的字符译解成自己可以理解的语言。
1882年，尼采买了台打字机。此时的他，视力下降得厉害，盯着纸看的时间长了，动不动头疼得要死，他担心会被迫停止写作。但打字机救了他。他终于熟能生巧，闭着眼睛也能打字——盲打。然而，新机器也使其作品的风格发生了微妙的变化。他的一个作曲家朋友为此写信给他，还说自己写曲子时，风格经常因纸和笔的特性不同而改变。
“您说得对，”尼采复信道，“我们的写作工具渗入了我们思想的形成。”德国媒体学者弗里德里希·基特勒则认为，改用打字机后，尼采的文风“从争辩变成了格言，从思索变成了一语双关，从繁琐论证变成了电报式的风格”。
卡尔引用神经学家的观点，证明成年人的大脑仍然颇具可塑性，而历史上机械钟表和地图的发明，同样说明了人类如何因此改变了对时间与空间的思维。互联网正是今日的钟表与地图。
网络影响让传统媒体也零碎化
当人们的思维方式适应了互联网媒体的大拼盘范式后，传统媒体也会做出改变。电视节目加入了滚动字幕和不断跳出的小广告，报刊则缩短其文章的长度，引入一小块一小块的摘要，在版面上堆砌各种易于浏览的零碎信息。今年3月，《纽约时报》便决定将其第2和第3版改为内容精粹。
Google 首席执行官埃里克·施密特说，该公司致力于将“一切系统化”。Google还宣布，其使命是“将全世界的信息组织起来，使之随处可得，并且有用。”通过开发“完美的搜索引擎，”让它能够“准确领会你的意图，并精确地回馈给你所要的东西。”问题是，它会使我们越变越蠢吗？
“我感觉得到。”卡尔最后说，库布里克黑色预言的实质在于：当我们依赖电脑作为理解世界的媒介时，它就会成为我们自己的思想。
上网阅读时，我们充其量只是一台“信息解码器”。
当我们依赖电脑作为理解世界的媒介时，它就会成为我们自己的思想