Posts

dictionary ‘CMMI 配置库’ 配置项,就一个项目整个的生命周期过程中,所产生的一切文档、程序以及需要进行控制的项目。 那么这些配置项所保存、管理的一个地方,就叫配置库。 配置库,有逻辑上的意义,也有物理上的意义 逻辑上,就是上文所说的 物理上,就是一些用来做配置管理的软件系统,比如说VSS之类 通过这些配置管理软件,对配置项进行管理和控制,那么整个软件系统就可以称作配置库。 阿特金森循环 这一名词早在1880年就存在了.是一种高压缩比，长膨胀行程的内燃机工作循环。 因为这种循环结构比较复杂,所以大家都选用了奥托循环式的发动机. 发动机理论最典型的就是吸气-压缩-燃烧膨胀-排气的循环.而奥托注册了许多专利,所以阿特金森不得不研发一种不使用正时带和凸轮轴的内燃机. 阿特金森发动机巧妙的只用一个飞轮带曲柄连杆机构实现了4个冲程. 阿特金森发动机的特点是使燃烧在气缸中的油/气混合物的体积膨胀得更大，借此让动力装置能更高效地利用燃油。 而现代阿特金森循环发动机(Atkinson cycle engine)使用电子控制装置和进气阀定时装置，通过推迟进气门关闭，在压缩冲程从进气门排出部分燃气，减少进气量，从而实现膨胀比大于压缩比，提高燃油利用率，达到节油的目的。 马克思发生器 马克思发生器 (Marx Generator) 是一种利用电容并联充电再串联放电的高压装置，该结构由E.Marx于1924年提出，它能模仿雷电及操作过电压等过程。 所以经常用于绝缘冲击耐压及介质冲击击穿、放电等试验中。 Mercurial Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。相对于传统的版本控制，具有如下优点: 更轻松的管理。 传统的版本控制系统使用集中式的 repository，一些和 repository 相关的管理就只能由管理员一个人进行。由于采用了分布式的模型，Mercurial 中就没有这样的困扰，每个用户管理自己的 repository，管理员只需协调同步这些repository。 更健壮的系统。 分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统通常不会因为一两个节点而受到影响。 对网络的依赖性更低。 由于同步可以放在任意时刻进行，Mercurial 甚至可以离线进行管理，只需在有网络连接时同步。 Redmine Redmine 是一个开源的、基于Web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及进度可视化显示。同时它又支持多项目管理。Redmine是一个自由开放 源码软件解决方案，它提供集成的项目管理功能，问题跟踪，并为多个版本控制选项的支持。 虽说像IBM Rational Team Concert的商业项目调查工具已经很强大了，但想坚持一个自由和开放源码的解决方案，可能会发现Redmine是一个有用的Scrum和敏捷的选择。 由于Redmine的设计受到Rrac的较大影响，所以它们的软件包有很多相似的特征。 Redmine建立在Ruby on Rails的框架之上，支持跨平台和多种数据库。。 Erlang Erlang 是一种通用的面向并发的编程语言，它由瑞典电信设备制造商爱立信所辖的 CS-Lab 开发，目的是创造一种可以应对大规模并发活动的编程语言和运行环境。Erlang是一个结构化，动态类型编程语言，内建并行计算支持。最初是由爱立信专门为通信应用设计的，比如控制交换机或者变换协议等，因此非常适 合于构建分布式，实时软并行计算系统。 使用 Erlang 编写出的应用运行时通常由成千上万个轻量级进程组成，并通过消息传递相互通讯。进程间上下文切换对于Erlang来说仅仅只是一两个环节，比起C程序的线程切换要高效得多得多了。 使用Erlang来编写分布式应用要简单的多，因为它的分布式机制是透明的: 对于程序来说并不知道自己是在分布式运行。 Erlang运行时环境是一个虚拟机，有点像Java虚拟机，这样代码一经编译，同样可以随处运行。它的运行时系统甚至允许代码在不被中断 的情况下更新。另外如果你需要更高效的话，字节代码也可以编译成本地代码运行。 Yaws: 一个Erlang写的服务器，据说并发性能是apache的15倍Erlang得名于丹麦数学家及统计学家Agner Krarup Erlang，同时Erlang还可以表示Ericsson Language。 ...

tomcat启动jvm内存设置 配置tomcat调用的虚拟机内存大小 (1) 直接设置tomcat Linux 修改TOMCAT_HOME/bin/catalina.sh 位置cygwin=false前。 JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m" (仅做参考，具体数值根据自己的电脑内存配置) windows 修改TOMCAT_HOME/bin/catalina.bat 第一行加上 JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m" (2) 配置环境变量 环境变量中设 变量名: JAVA_OPTS 变量值: -Xms512m -Xmx512m https://www.cnblogs.com/oskyhg/p/6549877.html

automation test tools 在世面上的自动化测试工具很多。有开源的，有商业化的，各有各得特色，各有各得优点！下面我就介绍几个我用过的开源自动化测试工具。 1 测试 WEB SELENIUM可以说是测试WEB最全面的开源自动化工具， 它可以在WINDOWS， LINUX, MAC 和 SOLARIS 上运行， 而且可以几乎用任何一种编程语言进行构建， 你可以用你熟悉的语言包括 JAVA， C＃， PERL， PHP， PYTHON 和 RUBY。 它可以测试的浏览器有IE， FIREFOX， OPERA 和 SAFARI。 SELENIUM 家族成员有: SELENIUM， SELENIUM RC， SELENIUM IDE， SELENIUM CORE， SELENIUM GRID 和 SELENIUM ON RAILS。 GOOGLE 每天都要在他的TESTING FARM上跑几万个SELENIUM测试CASE,现在也些会更多，你如果想学习SELENIUM， 可以从这里开始 http://selenium.seleniumhq.org/ **tellurium ** 这个框架是从Selenium框架{#ex48}发展而来，但又具有不同的测试理念。大多数Web测试框架，比如Selenium，主要致力于单独的UI元素。而Tellurium恰好相反，它把多个UI元素看作一个Widget整体，并将其称作UI module。

细化解析 不同类型数据库的死锁问题 论坛中有很多关于死锁问题的讨论，在理论方面，R.Ramakrishnan的《Database management systems》也有非常精辟的阐述。就实际开发而言，不同的数据库环境有着不同的处理方法，不同的体系架构也会导致不同的结果,下面来简单介绍一下不同类型数据库的死锁问题。 1.MSSQL、DB2、Oracle之类的现代DBMS或者中间件可以帮助我们自动解决绝大部分死锁，其余一部分难以处理的死锁则由DBA在数据库控制端手工处理。就应用程序而言，不需要在源代码级过多考虑地考虑死锁问题。 2.死锁的发生对系统的性能和吞吐量有着明显的影响，但只要存在针对共享数据资源的大规模并发访问的情况，那么死锁是不可避免的。 理论上，预防死锁的最好的途径是: 给每一个transaction设定一个优先级，同时确保较低优先级的事务不必等待较高优先级事务释放共享资源，反过来，也确保较高优先级的事务能够立刻取得相应的资源。如果开发人员无法判别事务的优先级，那么可以考虑在每个事务开始时赋予它一个的时间戳，依据时间戳的先后来判定事务的优先级，这类似于FIFO队列。在这方面，现代DBMS都提供了相应的语言支持。但是，假设由于网络故障而导致高优先级的事务无法commit或者rollback，那么是否其他低级别事务便要一直等待或者被抛弃？或者一个事务中的update操作施加了多个表级锁，并且占用了大量时间，那么即便这种事务从逻辑上并不合理，是否也要保持它的高优先级？ 针对稀缺资源的竞争在任何场合都是正常的，死锁出现的因果关系给予我一个提示，就是不能盲目地依赖DBMS和DBA在死锁发生后再去解决死锁问题，那样必然已经对用户体验造成了消极影响。开发人员在设计过程中，需要更多地研判可能的并发访问问题。这些问题可能包括: 尽可能缩短事务。在同一DB中并发执行多个需要长时间运行的事务时，发生死锁的概率较大。事务运行时间越长，其持有exclusive锁或update锁的时间便越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。同时，涉及多个表的查询更新操作，若比较耗时，尽量不要放在一个事务内处理，能分割便分割。若不能分割，便尽可能使之在业务量较小的时间(例如子夜或者午餐时间)执行。 尽可能按同一顺序访问数据对象。如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。 避免编写包含用户交互的事务。因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，若用户不能及时反馈，则此事务将挂起。因而将严重降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。 使用低隔离级别。确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取 (未修改) 的数据，而不必等待第一个事务完成。使用较低的隔离级别 (例如提交读) 而不使用较高的隔离级别 (例如可串行读) 可以缩短持有共享锁的时间，从而降低了锁定争夺。 考虑体系结构的优化与代码重构，提高系统整体的运行效率。例如尽可能不要采用类似EJB的效率低下的计算模型，或者将复杂的业务置于编译存储过程中执行。 通过程序控制事务提交的时机。如果一次检索出了10万条记录但只更改了其中的100条，就可以通过代码来执行100个update。或是用分段提交，即所有的修改使用多个事务进行提交，但这样会使事务不完整，应酌情使用。 将经常更新的数据库和查询数据库分开。定期将不改变的数据导入查询数据库中，这样查询和更新就可以分开进行，而降低死锁机率。 在进行数据库模式设计时，注意外键引用的完整性，并对外键加索引。如果更新了父表的主键，由于外键上没有索引，所以子表会被锁定；如果删除了父表中的一行，整个子表也会被锁定。

六个方法解决应用程序中死锁现象的出现 在应用程序中就可以采用下面的一些方法来避免死锁: (1) 合理安排表访问顺序。 (2) 在事务中尽量避免用户干预，尽量使一个事务处理的任务少些, 保持事务简短并在一个批处理中。 (3) 数据访问时域离散法, 数据访问时域离散法是指在客户机/服务器结构中，采取各种控制手段控制对数据库或数据库中的对象访问时间段。主要通过以下方式实现: 合理安排后台事务的执行时间，采用工作流对后台事务进行统一管理。工作流在管理任务时，一方面限制同一类任务的线程数 (往往限制为1个) ，防止资源过多占用; 另一方面合理安排不同任务执行时序、时间，尽量避免多个后台任务同时执行，另外， 避免在前台交易高峰时间运行后台任务。 (4) 数据存储空间离散法。数据存储空间离散法是指采取各种手段，将逻辑上在一个表中的数据分散到若干离散的空间上去，以便改善对表的访问性能。主要通过以下方法实现: 第一，将大表按行或列分解为若干小表; 第二，按不同的用户群分解。 (5) 使用尽可能低的隔离性级别。隔离性级别是指为保证数据库数据的完整性和一致性而使多用户事务隔离的程度，SQL92定义了4种隔离性级别: 未提交读、提交读、可重复读和可串行。如果选择过高的隔离性级别，如可串行，虽然系统可以因实现更好隔离性而更大程度上保证数据的完整性和一致性，但各事务间冲突而死锁的机会大大增加，大大影响了系统性能。 (6) 使用绑定连接, 绑定连接允许两个或多个事务连接共享事务和锁，而且任何一个事务连接要申请锁如同另外一个事务要申请锁一样，因此可以允许这些事务共享数据而不会有加锁的冲突。

如何解决数据库中的死锁问题 说道死锁问题的解决,一般情况下我们都是选择KILL进程,但如果不查出引起死锁的原因,死锁的现象则会频繁出现，其实只要通过查找引起死锁的操作,就可以方便的解决死锁。 **具体的解决方法如下: ** 1.再死锁发生时,我们可以通过下面的语法,查询到引起死锁的操作: use master go declare @spid int,@bl int DECLARE s_cur CURSOR FOR select 0 ,blocked from (select * from sysprocesses where blocked>0 ) a where not exists(select * from (select * from sysprocesses where blocked>0 ) b where a.blocked=spid) union select spid,blocked from sysprocesses where blocked>0 OPEN s_cur FETCH NEXT FROM s_cur INTO @spid,@bl WHILE @@FETCH_STATUS = 0 begin if @spid =0 select ‘引起数据库死锁的是: ‘+ CAST(@bl AS VARCHAR(10)) + ‘进程号,其执行的SQL语法如下’ ...

死锁 (Deadlocks) deadlocks (死锁) 所谓死锁: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程. 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。 一种情形，此时执行程序中两个或多个线程发生永久堵塞 (等待) ，每个线程都在等待被其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。 计算机系统中,如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因竞争资源不当而产生死锁的现象。 产生死锁的原因主要是: (1) 因为系统资源不足。 (2) 进程运行推进的顺序不合适。 (3) 资源分配不当等。 如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则 就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。 产生死锁的四个必要条件: (1) 互斥条件: 一个资源每次只能被一个进程使用。 (2) 请求与保持条件: 一个进程因请求资源而阻塞时，对已获得的资源保持不放。 (3) 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。 (4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之 一不满足，就不会发生死锁。 死锁的解除与预防: 理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和 解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确 定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态 的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。

agile scrum tools Trello wekan https://github.com/wekan/wekan podman run -d --name wekan-db -p 27017:27017 mongo:4.4 podman run -d --name wekan -e "WITH_API=true" -e "MONGO_URL=mongodb://192.168.50.13:27017/wekan" -e "ROOT_URL=http://192.168.50.13:2000" -p 2000:8080 wekanteam/wekan:v5.41 podman run -d --name wekan-db -p 27017:27017 mongo:5.0.9 podman run -d --name wekan -e "WITH_API=true" -e "MONGO_URL=mongodb://192.168.50.16:27017/wekan" -e "ROOT_URL=http://192.168.50.16:2000" -p 2000:8080 wekanteam/wekan:v6.30 Rally 商业软件用户使用率排名第二位！支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则 (notification rules) ，以及用于Eclipse和CruiseControl.NET的连接器。 有免费在线试用体验版本. VersionOne 商业化产品！没什么好说的，业界老大 从 功能上看，的确非常新颖，贯彻了敏捷中的User Story为先的原则，和VSTS类似，将Issues、Defect、Task合并概念成为Task(在VSTS中更加优雅，叫做WorkItem)， 并且必须挂在UserStory下，这个工具值得看看，有试用版可以下载，或者可以使用他们在线提供的试验平台 基于ASP.NET and IIS和 SQL。 团队可以使用"V1: 敏捷团队"来管理产品和sprint backlog，通过交互式的"任务板 (taskboards) “和"测试板 (testboards) " 进行每日开发活动，藉由报表和燃烧图查看进度，以及其他活动。 通过这些功能，“V1: 敏捷团队"的用户可以做到: ...

动态代理 Dynamic Proxy 从JDK1.3开始，Java就引入了动态代理的概念。动态代理 (Dynamic Proxy) 可以帮助你减少代码行数，真正提高代码的可复用度。例如，你不必为所有的类的方法里面都写上相同的Log代码行，取而代之的是实用类的动态代理类。当然，这种便利是有条件的。本文简单介绍Java动态代理的原理，并实现一个被代理的Servlet创建，和调用的过程。 代理模式 (Proxy Pattern) 在JDK1.3以前，代理模式就已流行，所以得代理模式是生成一个和类相同接口的代理类，用户通过使用代理类来封装某个实现类。如图1，其目的是加强实现类的某个方法的功能，而不必改变原有的源代码。 <img src="http://p.blog.csdn.net/images/p_blog_csdn_net/tyrone1979/proxy1.JPG" alt="" /> 2．动态代理 (Dynamic Proxy) 随着Proxy的流行，Sun把它纳入到JDK1.3实现了Java的动态代理。动态代理和普通的代理模式的区别，就是动态代理中的代理类是由java.lang.reflect.Proxy类在运行期时根据接口定义，采用Java反射功能动态生成的。和java.lang.reflect.InvocationHandler结合，可以加强现有类的方法实现。如图2，图中的自定义Handler实现InvocationHandler接口，自定义Handler实例化时，将实现类传入自定义Handler对象。自定义Handler需要实现invoke方法，该方法可以使用Java反射调用实现类的实现的方法，同时当然可以实现其他功能，例如在调用实现类方法前后加入Log。而Proxy类根据Handler和需要代理的接口动态生成一个接口实现类的对象。当用户调用这个动态生成的实现类时，实际上是调用了自定义Handler的invoke方法。 <img src="http://p.blog.csdn.net/images/p_blog_csdn_net/tyrone1979/proxy2.JPG" alt="" width="683" height="284" /> 3．动态代理Servlet 虽然Web Application Server的产品很多，但Servlet的处理原理是相似的: 动态加载Servlet，调用Servlet的init方法 (只被调用一次) ，并保存到Servlet容器；Servlet使用时，调用Servlet的service方法。本文动态代理Servlet接口，使其init和service被调用时会在控制台打出方法调用前后信息。 首先实现2个Servlet，DefaultServlet和UserServlet ```java package org.colimas.servlet; import javax.servlet.Servlet; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; public class DefaultServlet extends HttpServlet implements Servlet { public void init() throws ServletException { super.init(); System.out.println(DefaultServlet.class.getName()+":Running init"); } public String getServletInfo() { return DefaultServlet.class.getName(); } } package org.colimas.servlet; import java.io.IOException; import javax.servlet.Servlet; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class UserServlet extends HttpServlet implements Servlet { private static final long serialVersionUID = -7016554795165038652L; public void init() throws ServletException { super.init(); System.out.println(UserServlet.class.getName()+":Running init"); } protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.out.println(UserServlet.class.getName()+":Do UserSErvlet Get"); } public String getServletInfo() { return UserServlet.class.getName(); } } 然后实现InvocationHandler ...

Arrays.binarySearch() Arrays.binarySearch();的用法。 public static int binarySearch(Object[] a,Object key) 使用二分搜索法来搜索指定数组，以获得指定对象。在进行此调用之前， 必须根据元素的自然顺序对数组进行升序排序 (通过 sort(Object[]) 方 法 ) 。如果没有对数组进行排序，则结果是不确定的。 (如果数组包 含不可相互比较的元素 (例如，字符串和整数) ，则无法 根据其元素的自 然顺序对数组进行排序，因此结果是不确定的。) 如果数组包含多个等于 指定对象的元素，则无法保证找到的是哪一个。 参数: a - 要搜索的数组 key - 要搜索的值 返回: 如果它包含在数组中，则返回搜索键的索引；否则返回 (-(插入点) - 1) 。插入点 被定义为将键插入数组的那一点: 即第一 个大于此键的 元素索引，如果数组中的所有元素都小于指定的键，则为 a.length。注意 ，这保证了当且仅当此键被找到时，返回的值将 >= 0。 否则返回 (-(插入点) - 1)这句话要注意: 要是查询的的值小于数组里面 的最小值那么结果(-(0)-1结果就是-1)，如果查询的 值大于数组里面的 最大值。那么结果就是(-(它的索引值)-1结果就是-(1+索引值)) 抛出: ClassCastException - 如果搜索的键不能与数组的元素进行比较。

synchronized 多线程 在现代计算机中往往存在多个CPU核心，而1个CPU能同时运行一个线程，为了充分利用CPU多核心，提高CPU的效率，多线程就应时而生了。 那么多线程就一定比单线程快吗? 答案是不一定，因为多线程存在单线程没有的问题 上下文切换 线程执行过程中发生系统调用或者线程调度时都会发生上下文切换 线程从运行状态切换到阻塞状态或者等待状态的时候需要将线程的运行状态保存，线程从阻塞状态或者等待状态切换到运行状态的时候需要加载线程上次运行的状态。线程的运行状态从保存到再加载就是一次上下文切换，而上下文切换的开销是非常大的，而我们知道CPU给每个线程分配的时间片很短，通常是几十毫秒(ms)，那么线程的切换就会很频繁。 死锁 死锁的一般场景是，线程A和线程B都在互相等待对方释放锁，死锁会造成系统不可用。 资源限制的挑战 资源限制指计算机硬件资源或软件资源限制了多线程的运行速度，例如某个资源的下载速度是1Mb/s，资源的服务器带宽只有2Mb/s，那么开10个线程下载资源并不会将下载速度提升到10Mb/s。 既然多线程存在这些问题，那么我们在开发的过程中有必要使用多线程吗？我们知道任何技术都有它存在的理由，总而言之就是多线程利大于弊，只要我们合理使用多线程就能达到事半功倍的效果。 多线程的意思就是多个线程同时工作，那么多线程之间如何协同合作，这也就是我们需要解决的线程通信、线程同步问题 线程通信 线程通信指线程之间以何种机制来交换消息，线程之间的通信机制有两种: 共享内存和消息传递。共享内存即线程通过对共享变量的读写而达到隐式通信，消息传递即线程通过发送消息给对方显示的进行通信。 线程同步 线程同步指不同线程对同一个资源进行操作时候线程应该以什么顺序去操作，线程同步依赖于线程通信，以共享内存方式进行线程通信的线程同步是显式的，以消息传递方式进行线程通信的线程同步是隐式的。 synchronized synchronized 的锁机制的主要优势是Java语言内置的锁机制，因此，JVM可以自由的优化而不影响已存在的代码。 synchronized 是 Java 的关键字，可用于同步实例方法、类方法(静态方法)和代码块 同步实例方法: 当 synchronized 修饰实例方法 (函数修饰符）的时候，同步的范围是当前实例的实例方法。 同步类方法(静态方法): 当 synchronized 修饰类方法的时候，同步的范围是当前类的方法。用synchronized修饰方法名时，编译后会在方法名上生成一个ACC_SYNCHRONIZED标识来实现同步 同步代码块: 当 synchronized 修饰代码块的时候，同步的范围是()中的对象。当使用synchronized修饰代码块时，编译后会在代码块的前后生成monitorenter和monitorexit字节码来实现同步。 synchronized 是非公平锁 synchronized 关键字经过编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令，这两个字节码需要关联到一个监视对象，当线程执行 monitorenter 指令时，需要首先获得获得监视对象的锁，这里监视对象锁就是进入同步块的凭证，只有获得了凭证才可以进入同步块，当线程离开同步块时，会执行 monitorexit 指令，释放对象锁。 synchronized 关键字，代表这个方法加锁,相当于不管哪一个线程 (例如线程A) ，运行到这个方法时, 都要检查有没有其它线程B (或者C、 D等) 正在用这个方法，有的话要等正在使用 synchronized 方法的线程B (或者C 、D) 运行完这个方法后再运行此线程 A,没有的话,直接运行。 markword markword 数据的长度在32位和64位的虚拟机 (未开启压缩指针) 中分别为32bit和64bit，它的最后2bit是锁状态标志位，用来标记当前对象的状态，对象的所处的状态，决定了markword存储的内容 ...

单例 Singleton 静态内部类 static nested class 这种方法也是《Effective Java》上所推荐的。 这种写法仍然使用JVM本身机制保证了线程安全问题；由于 SingletonHolder 是私有的，除了 getInstance() 之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本。 这是利用了JVM的特性：静态内部类时在类加载时实现的，因此不会受到多线程的影响，自然也就不会出现多个实例。 public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } private Singleton() { } public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } } 单例模式 (Singleton) 介绍: 也叫单子模式，是一种常用的软件设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。 实现单例模式的思路是: 一个类能返回对象一个引用(永远是同一个)和一个获得该实例的方法 (必须是静态方法，通常使用getInstance这个名称)； 当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用；同时我们还将该类的构造函数定义为私有方法，这样其他处的代码就无法通过调用该类的构造函数来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例。 注意事项: 单例模式在多线程的应用场合下必须小心使用。如果当唯一实例尚未创建时，有两个线程同时调用创建方法，那么它们同时没有检测到唯一实例的存在，从而同时各自创建了一个实例，这样就有两个实例被构造出来，从而违反了单例模式中实例唯一的原则。 解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁(虽然这样会降低效率)。 实现方式: 通常单例模式在Java语言中，有两种构建方式: 饿汉方式:指全局的单例实例在类装载时构建。(一般认为这种方式要更加安全些) ...

UML 中关联，聚合，组合的区别 关联 Association 聚合 Aggregation Composition 类间关系 在类图中，除了需要描述单独的类的名称、属性和操作外，我们还需要描述类之间的联系，因为没有类是单独存在的，它们通常需要和别的类协作，创造比单独工作更大的语义。在 UML 类图中，关系用类框之间的连线来表示，连线上和连线端头处的不同修饰符表示不同的关系。类之间的关系有继承 (泛化) 、关联、聚合和组合。 关联 (Association) 关联指的是模型元素之间的一种语义联系，是类之间的一种很弱的联系。关联可以有方向，可以是单向关联，也可以是双向关联。可以给关联加上关联名来描述关联的作用。关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个对象参与关联。可以通过关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。对于关联可以加上一些约束，以加强关联的含义。 class A: pass class B: def func_0(a:A) # 一个类作为另一个类方法的参数 聚合 (aggregation) 指的是整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力攻击潜艇等。需求描述中"包含"、“组成”、“分为…部分"等词常意味着聚合关系。 在聚合中，所包含的类并不强烈依赖于容器的生命周期。在同一示例中，即使图书馆解散，书籍仍将保留。 聚合使用一个带有 空心菱形 的箭头表示，菱形指向"整体"类。 class School class Student Student --o School 组合 (composition) 也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。 组合使用一个带有 实心菱形 的箭头表示，菱形指向"整体"类。 class Person class Heart Heart --* Person 聚合和组合的区别在于: 聚合关系是"has-a"关系，组合关系是"contains-a"关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。 我们用浅显的例子来说明聚合和组合的区别。"国破家亡"，国灭了，家自然也没有了，"国"和"家"显然也是组合关系。而相反的，计算机和它的外设之间就是聚合关系，因为它们之间的关系相对松散，计算机没了，外设还可以独立存在，还可以接在别的计算机上。在聚合关系中，部分可以独立于聚合而存在，部分的所有权也可以由几个聚合来共享，比如打印机就可以在办公室内被广大同事共用。 在C++语言中，从实现的角度讲，聚合可以表示为: class A {...} class B { A* a; .....} 即类B包含类A的指针； 而组合可表示为: class A{...} class B{ A a; ...} 即类B包含类A的对象。 准确的UML类图中用空心和实心菱形对聚合和组合进行了区分。 关联和聚合的区别主要在语义上，关联的两个对象之间一般是平等的，例如你是我的朋友，聚合则一般不是平等的，例如一个公司包含了很多员工，其实现上是差不多的。聚合和组合的区别则在语义和实现上都有差别，组合的两个对象之间其生命期有很大的关联，被组合的对象是在组合对象创建的同时或者创建之后创建，在组合对象销毁之前销毁。一般来说被组合对象不能脱离组合对象独立存在，而且也只能属于一个组合对象，例如一个文档的版本，必须依赖于文档的存在，也只能属于一个文档。聚合则不一样，被聚合的对象可以属于多个聚合对象，例如一个员工可能可以属于多个公司。 我想举个通俗的例子。 你和你的心脏之间是composition关系 (心脏只属于你自己) 你和你买的书之间是aggregation关系 (书可能是别人的) 你和你的朋友之间是assoc 继承 (Extension) 指的是一个类 (称为子类) 继承另外的一个类 (称为基类) 的功能，并增加它自己的新功能的能力，继承是类与类之间最常见的关系。 ...

out of the box out of the box: “Out of box"用于描述某种不确定的事件。常常作为副词来形容某种观点的不确定性。据说这个词同20世纪早期的英国数学家亨利?恩斯特?杜德耐解答一个著名数学谜语的思路相关。题目要求用四条直线连接平面上三乘三分布的九个点，要求一笔连成，也就是在画线的时候笔不能离开纸面。解决这个数学问题的关键在于要克服传统的在三乘三边界内画点的思想，如果将线连接到边界之外，那么问题可以迎刃而解，这样就产生了"Out of box"这个词。相应的，将思维受限这种情况称为"boxed－in”。在IT领域，节奏变化很快，因此每个人都在寻找"Out of box"的思维方式，尝试创新。 用"In the box"表示某种确定的事情。比如，最近有一篇文章讨论了MP3以及盗版音乐的关系，其中引用了一位业内人士的话表示: “主流唱片公司很少关心互联网上的发展，他们的思维就是’Inside the box’"。 “Out of the box”(开箱即用)也用作"off the shelf” (现货供应) 的同义词，其含义是指能够满足一定需求的、已经作好了的软件、硬件或两者的结合形式。如不采用，就需要投入专门的人力物力来开发。 out-of-the-box具有"创造性的，独特性，思维不合常规"的意思，但在计算机术语里又可以指"从盒子里拿出来直接可以使用的，也就是即开即用"的意思。“out-of-the-box” is similar to “off-the-shelf”, usually referinng to software/hardware which can be used as is, not requiring extra customisation or add-on components.

多普勒效应 多普勒效应是为纪念奥地利物理学家及数学家克里斯琴·约翰·多普勒 (Christian Johann Doppler) 而命名的，他于1842年首先提出了这一理论，主要内容为: 物体辐射的波长因为波源和观测者的相对运动而产生变化。在运动的波源前面，波被压缩，波长变得较短，频率变得较高 (蓝移_blue shift_) ；当运动在波源后面时，会产生相反的效应。波长变得较长，频率变得较低 (红移_red shift_) ；波源的速度越高，所产生的效应越大。根据波红 (蓝) 移的程度，可以计算出波源循着观测方向运动的速度。 恒星光谱线的位移显示恒星循着观测方向运动的速度，除非波源的速度非常接近光速，否则多普勒位移的程度一般都很小。所有波动现象都存在多普勒效应. 1842年奥地利一位名叫多普勒的数学家、物理学家。一天，他正路过铁路交叉处，恰逢一列火车从他身旁驰过，他发现火车从远而近时汽笛声变响，音调变尖，而火车从近而远时汽笛声变弱，音调变低。他对这个物理现象感到极大兴趣，并进行了研究。发现这是由于振源与观察者之间存在着相对运动，使观察者听到的声音频率不同于振源频率的现象。这就是频移现象。因为，声源相对于观测者在运动时，观测者所听到的声音会发生变化。当声源离观测者而去时，声波的波长增加，音调变得低沉，当声源接近观测者时，声波的波长减小，音调就变高。音调的变化同声源与观测者间的相对速度和声速的比值有关。这一比值越大，改变就越显著，后人把它称为"多普勒效应"。

VTune 英特尔VTune™ 性能分析器 英特尔VTune™ 性能分析器可通过图形用户界面轻松优化应用性能，而且无需重新编译。它独立于编译器和语言，因此可与 C、C++、Fortran、C#、Java、.NET 等等†一起使用。与只提供调用图分析或一组有限的采样事件的产品不同，VTune 分析器可通过一组丰富的适用于所有最新英特尔® 处理器的调试事件同时实现上述两种功能。 开发出在运行 Microsoft Windows Vista*、Windows* XP 或 Windows Server* 的最新 64 位多核系统上运行如飞的软件。无需重新编译，并且只需极低的开销 (不到 5%) ，便可以确定性能瓶颈。使用图形界面与强大的 Visual Studio* 与 .NET 集成功能来分析结果。快速探查源代码，确定存在问题的代码行。 优化多核性能 内含英特尔线程档案器！对应用进行线程处理后并没有达到您预期的效果？英特尔线程档案器可帮助您调试多线程代码，从而在当今的多核处理器上取得最佳性能。 英特尔VTune™ 性能分析器 Linux* 版是完全基于 Linux 的解决方案，无论是在单核系统上还是在多核系统上，要使您的软件以最快速度运行，该解决方案都是不可或缺的。无需重新编译，也无需通过超级计算机系统在手持设备上链接，它便能分析应用程序。它功能强大，可处理大型应用程序 (源代码超过 1 GB) ，并支持多核多处理器以及使用最新英特尔处理器的 NuMA 系统。

GNU profiler 各种软件对于性能的需求可能会有很大的区别，但是很多应用程序都有非常严格的性能需求，这一点并不奇怪。电影播放器就是一个很好的例子: 如果一个电影播放器只能以所需要速度的 75% 来播放电影，那么它几乎就没什么用处了。 其他应用程序 (例如视频编码) 如果是耗时非常长的操作，最好以 “批处理” 任务的方式运行，此时启动一个作业，让其一直运行，然后我们就可以去干别的事情了。尽管这些类型的应用程序没有这种硬性性能指标的限制，但是提高速度仍然会带来很多好处，例如可以在给定的时间内可以对更多电影进行编码，在同样的时间内可以以更高的品质进行编码。 通常，除了最简单的应用程序之外，对于其他应用程序来说，性能越好，这个应用程序的用处就越大，也就会越流行。由于这个原因，性能考虑是 (也应该是) 很多应用程序开发人员脑袋中的第一根弦。 不幸的是，很多尝试让应用程序速度更快的努力都白费了，因为开发人员通常都是对自己的软件进行一些_小型的优化_，而没有去研究程序在更大的范围内是如何操作的。例如，我们可能会花费大量的时间来让某个特定函数的运行速度达到原来的两倍，这一点非常不错，但是如果这个函数很少被调用 (例如打开文件) ，那么将这个函数的执行时间从 200ms 减少到 100ms，对于整个软件的总体执行时间来说并不会有太大的影响。 有效地利用您的时间的方法是，尽量优化软件中被频繁调用的部分。例如，假设应用程序花了 50% 的时间在字符串处理函数上，如果可以对这些函数进行优化，提高 10% 的效率，那么应用程序的总体执行时间就会改进 5%。 因此，如果希望能够有效地对程序进行优化，那么精确地了解时间在应用程序中是如何花费的，以及_真实的输入数据_，这一点非常重要。这种行为就称为_代码剖析 (code profiling) _。本文将简要介绍 GNU 编译器工具包所提供的一种剖析工具，它的名字让人可以产生无限遐想，叫 GNU profiler (gprof) 。

汽车知识入门 http://www.tianya.cn/publicforum/content/cars/1/254081.shtml 汽车知识入门 MPV–MPV的全称是Multi-Purpose Vehicle，即多用途汽车。它集轿车、旅行车和厢式货车的功能于一身，车内每个座椅都可调整，并有多种组合的方式，例如可将中排座椅靠背翻下即可变为桌台，前排座椅可作180度旋转等。近年来，MPV趋向于小型化，并出现了所谓的S—MPV，S是小(Small)的意思。S-MPV车长一般在(4.2—4.3)m之间，车身紧凑，一般为(5-7)座。 SUV–SUV的全称是Sport Utility Vehicle，中文意思是运动型多用途汽车。现在主要是指那些设计前卫、造型新颖的四轮驱动越野车。SUV一般前悬架是轿车型的独立悬架，后悬架是非独立悬架，离地间隙较大，在一定程度上既有轿车的舒适性又有越野车的越野性能。由于带有MPV式的座椅多组合功能，使车辆既可载人又可载货，适用范围广。 RV–RV的全称是Recreation Vehicle，即休闲车，是一种适用于娱乐、休闲、旅行的汽车，首先提出RV汽车概念的国家是日本。RV的覆盖范围比较广泛，没有严格的范畴。从广义上讲，除了轿车和跑车外的轻型乘用车，都可归属于RV。MPV及SUV也同属RV。 皮卡–皮卡(PICK-UP)又名轿卡。顾名思义，亦轿亦卡，是一种采用轿车车头和驾驶室，同时带有敞开式货车车厢的车型。其特点是既有轿车般的舒适性，又不失动力强劲，而且比轿车的载货和适应不良路面的能力还强。最常见的皮卡车型是双排座皮卡，这种车型是目前保有量最大，也是人们在市场上见得最多的皮卡。 CKD汽车–CKD是英文Completely Knocked Down的缩写，意思是"完全拆散"。换句话说,CKD汽车就是进口或引进汽车时,汽车以完全拆散的状态进入，之后再把汽车的全部零部件组装成整车。我国在引进国外汽车先进技术时，一开始往往采取CKD组装方式，将国外先进车型的所有零部件买进来，在国内汽车厂组装成整车。 SKD汽车–SKD是英文Semi—Knocked Down的缩写，意思是"半散装"。换句话说，SKD汽车就是指从国外进口汽车总成(如发动机、驾驶室、底盘等)，然后在国内汽车厂装配而成的汽车。SKD相当于人家将汽车做成"半成品"，进口后简单组装就成整车。 零公里汽车–零公里汽车是一个销售术语，指行驶里程为零(或里程较低，如不高于10km)的汽车，它的出现是为了满足客户对所购车辆"绝对全新"的要求。零公里表示汽车从生产线上下来后，还未有任何入驾驶过。为了保证里程表的读数为零，从生产厂到各销售点，均采用大型专用汽车运输，以保证车辆全新。 概念车–概念车由英文Conception Car意译而来。概念车不是即将投产的车型，它仅仅是向人们展示设汁人员新颖、独特、超前的构思而已。概念车还处在创意、试验阶段，很可能永远不投产。因为不足大批量生产的商品车，每一辆概念车都可以更多地摆脱生产制造水平方面的束缚，尽情地甚至夸张地展示自己的独特魅力。 概念车是时代的最新汽车科技成果，代表着未来汽车的发展方向，因此它展示的作用和意义很大，能够给人以启发并促进相互借鉴学习。因为概念车有超前的构思，体现了独特的创意，并应用了最新科技成果，所以它的鉴赏价值极高。 世界各大汽车公司都不惜巨资研制概念车，并在国际汽车展上亮相，一方面了解消费者对概念车的反映，从而继续改进；另一方面也是为了向公众显示本公司的技术进步，从而提高自身形象。 老爷车–老爷车也叫古典车，一般指20年前或更老的汽车。老爷车是一种怀旧的产物，是人们过去曾经使用的，现在仍可以工作的汽车。 老爷车这一概念始于20世纪70年代，最早出现在英国的一本杂志上，这种说法很快得到老爷车爱好者的认同。不到10年功夫，关注老爷车的人就越来越多，致使老爷车的身价戏剧性地增长起来。例如，一辆1933年款式的美国求盛伯格汽车在拍卖行卖到100万美元，一辆布加迪老爷车卖到650万美元。 零排放汽车–零排放汽车是指不排出任何有害污染物的汽车，比如太阳能汽车、纯电动汽车、氢气汽车等。有时人们也把零排放汽车称为绿色汽车、环保汽车、生态汽车、清洁汽车等。 电动汽车–目前人们所说的电动汽车多是指纯电动汽车，即是一种采用单一蓄电池作为储能动力源的汽车。它利用蓄电池作为储能动力源，通过电池向电机提供电能，驱动电动机运转，从而推动汽车前进。从外形上看，电动汽车与日常见到的汽车并没有什么区别，区别主要在于动力源及其驱动系统。 混合动力汽车–混合动力汽车就是在纯电动汽车上加装一套内燃机，其目的是减少汽车的污染．提高纯电动汽车的行驶里程。混合动力汽车有串联式和并联式两种结构形式。 燃气汽车–燃气汽车主要有压缩天然气汽车(简称LPG汽车或LPGV)和压缩天然气汽车(简称CNG汽车或CNGV)。顾名思义,LPG汽车是以液化石油气为燃料,CNG汽车是以压缩天然气为燃料,燃气汽车的CO排放量比汽油车减少90％以上，碳氢化合物排放减少70％以上，氮氧化合物排放减少35％以上，是目前较为实用的低排放汽车。 手动变速器 (MT) 手动变速器，也称手动挡，即用手拨动变速杆才能改变变速器内的齿轮啮合位置，改变传动比，从而达到变速的目的。 自动变速器 (AT) 自动变速器，利用行星齿轮机构进行变速，它能根据油门踏板程度和车速变化，自动地进行变速。而驾驶者只需操纵加速踏板控制车速即可。一般来讲，汽车上常用的自动变速器有以下几种类型: 液力自动变速器、液压传动自动变速器、电力传动自动变速器、有级式机械自动变速器和无级式机械自动变速器等。其中，最常见的是液力自动变速器。 无级变速器 (CVT) 无级变速器是由两组变速轮盘和一条传动带组成的。因此，其比传统自动变速器结构简单，体积更小。另外，它可以自由改变传动比，从而实现全程无级变速，使汽车的车速变化平稳，没有传统变速器换挡时那种"顿"的感觉。 手自一体变速器 手自一体变速器由德国保时捷车厂在911车型上首先推出，称为Tiptronic，它可使高性能跑车不必受限于传统的自动挡束缚，让驾驶者也能享受手动换挡的乐趣。此型车在其挡位上设有"+"、"－“选择挡位。在D挡时，可自由变换降挡 (－) 或加挡 (+) ，如同手动挡一样。驾驶者可以在入弯前像手动挡般的强迫降挡减速，出弯时可以低中挡加油出弯。现在的自动挡车的方向盘上又增加了”+"、"－“换挡按钮，驾驶者就能手不离开方向盘加减挡。 手动与自动主要有三方面的区别: 一是操控方式不同。手动档需要驾驶者配合离合器进行换档操作，自动档则由变速箱根据设定的传动比来操作，不需要人工干预。 二是驾驶感觉不同。手动档强调人的主观能动性，能充分唤起驾驶者的驾驶欲望和某种成就感。自动档则没有什么驾驶乐趣，讲究实用、省力。 三是油耗不同。相同品牌、排量的汽车，手动档车比自动档车省油10%左右。 AT也就是常说的自动档，MT就是手动档。在游戏默认为自动档，可以通过选项中的进行调整。那么他们有什么区别呢？简单的说，AT车换档全由车辆自己控制，MT需要人工干预。所以自动档的车开起来比较方便。自动档的汽车有很诱人的优点，首先是不用操所离合器。手动档的汽车要开好，关键是油离的配合，弄不好还会造成车辆损坏，而自动档的车，只要放到D档，驾驶者就只需要考虑油门和刹车了。再有的好处就是上坡起步不会失误，坡起一直是新手的难关，油离刹要全面的配合，常常让人手忙脚乱，而自动档的车在松开刹车准备起步时，车辆也不会后溜。 当然，自动档也有缺点。首当其从的就是动力传输效率不高，手动变速箱的机械效率大约在95%，而自动变速箱只有可怜的88%左右。另一个缺点就是制动功能，除了刹车有制动效果之外，引擎本身也有制动效果: 松开油门时，引擎的制动效果就开始发挥作用，如果从高档降入低档，制动效果更明显。 手动档的车有驾驶的乐趣，而自动档的车开起来轻松又愉快，所以现在越来越多的车开始提供自手动变速器。 车辆类型 什么是FF、FR、MR、4WD。FF: 前置引擎，前轮驱动。这种类型的车大部分机械配件都在车头，重量分配不均 (头重尾轻) ，加上转向轮和驱动轮都是前轮，容易产生转向不足。所以这种车不适合跑车，但它造价便宜，所以大部分市售车都是这种配置。FR: 前置引擎，后轮驱动。这种车具有天生的运动性能，转向灵活，甚至后有些转向过度，很多高性能的跑车都是这种配置。MR: 中置引擎，后轮驱动。相对于FF的转型不足、FR的转向过渡，MR正好适中。以运动性能而言，MR是最最理想的。不过引擎在车体中间，不但占用了空间，而且发出的噪音和热量都很容易传到车厢内，只有追求终极运动性能的跑车才会使用这种配置，如F1、又如兰博基尼。4WD: 4轮驱动。4轮驱动的车4只轮胎都有驱动力，所以他的抓地力比其他车都好，而且越野性能好，过弯稳重，这种车不限制引擎的安装位置。但4WD的车一般都很重，限制了它的动力发挥，它一般设计为拉力赛准备。AWD: 这其实也是4轮驱动，不过它特指全时4轮驱动 (All-time-4WD) ，普通的4WD只有在地牵引力时才启动4WD模式，所以也被称为分时4轮驱动。而AWD则不管什么时候都是4轮驱动模式。 马力和扭力 马力和扭力，都是引擎动力的表现。有人说"加速靠扭力，极速靠马力”。这句话其实是片面的，看完本篇你就会知道。扭力在物理学上正确的说法是扭矩，由于说成扭力的人太多，以讹传讹就变成了扭力。扭矩是推动汽车前进的根本原因。扭矩其实在初中的物理就已经学过，大致好像是这样"垂直方向的力乘上距离旋转中心点的距离"，单位是 (牛顿*米) ，也可以换成公制单位 (公斤*米) 或者英制单位 (磅*英尺) 。说道汽车时，扭矩的单位一般写成"N*M/rpm"，即在多少转时有多少扭矩。马力实际上也不是一种力，它是功率。引擎功率的计算也很简单: 功率(W)??2 pi × 扭矩(N-m)×转速(rpm)/60。它是衡量引擎综合表现的一个重要依据。马力在定义中是这样说的，以公制马力来讲: 一匹马于一分钟内将75公斤的物体拉动60公尺，计算得到1PS=4500kg-m/min，换算成秒1PS=75kg-m/sec，再以1W=9.8kg-m/sec来换算，得到1PS=735W。而马力又是由扭矩计算而来的，还是以公制的马力PS来说，PS=扭矩(N-m)*9.8m/sec2*rpm/716。现在，我们知道了，引擎产生了扭矩，而扭矩和转速共同作用产生了功率，而一部引擎功率的大小则是这部引擎综合能力的关键，所以"大马力决定真性能"。现在我们再回到本篇开始时的那个问题: “加速靠扭力，极速靠马力”。从公式可以知道大马力的原因是"高转速的时候仍保有高扭矩数值"，也就是说要有大马力，不只是低转速的扭力要好，连高转速的扭力都得继续维持。就算在低转速时的扭矩有很大，如果没有转速的支持那轮胎依然得不到足够的转速来前进。这表示扭矩与马力的争论根本是多余的，只要能做到高马力，除了表示各转速区域的扭力都很大之外，更代表材料技术的优越性，将活塞、进排气阀门的材质与重量予以强化与轻量化，才能将引擎转速提高。说白了，这一篇讨论的就是引擎。在U2中可以给我调校的引擎参数只有ECU。ECU负责控制引擎在各个转速区域内的扭矩输出，前面已经说过引擎大马力表现的原因是高转速的时候仍保有高扭矩数值。所以，ECU在调校时可以将扭矩峰值之后的转速区域的ECU值调到最高，这样有效增加了高转速的扭矩输出，这样的车开起来会觉得动力充沛，特别是在6000转以上时，动力输出平滑而有力。 ...

Builder, Factory http://www.cnblogs.com/shenfx318/archive/2007/01/28/632724.html 在设计模式的学习过程中，Builder与Factory是创建模式中两个经典的教程，给与了我们很多值得汲取的宝贵设计思想，然而Builder与Factory模式也是初学者容易混淆的两个模式，经常看到有人问及两者的区别与适用的场景，我在近一段设计模式的学习过程中同样碰到了这个问题，在两种模式的区别与联系间我看到的更多是后者，在这里愿意与大家分享一些我对Builder与Factory模式的感悟，有说的不对的地方，还请各位多加提点、指教。 写在前面 本文旨在两种模式间的对比与探讨，因此还希望各位看官首先对两个模式有一定的了解为好，因为常常看到有人提问说，Builder模式与抽象工厂 (Abstract Factory) 之间的区别，其实在我看来这两者间并无太多联系，因此也就谈不上区别，至于原因在此不做细述，有兴趣的朋友可以看看我写的有关 http://www.cnblogs.com/shenfx318/archive/2007/01/16/621237.html 抽象工厂的文章。故本文中所提的Factory模式皆指的是工厂方法 (Factory Method) 。 从Builder到Factory的演化 先来看看Builder模式，Builder模式的一般设计及实现 ```java public interface IBuilder { void BuildPart1(); void BuildPart2(); Product GetResult(); } //ConcreteBuilderA public class BuilderA : IBuilder { private Product product; public void BuildPart1() { product = new Product(); product.Add(“Part1 build by builderA”); } public void BuildPart2() { product.Add(“Part2 build by builderA”); } public Product GetResult() { return product; } } } //ConcreteBuilderB public class BuilderB : IBuilder //Director public class Director { public void Construct(IBuilder builder) { builder.BuildPart1(); builder.BuildPart2(); } } ...

持续改进，抽象工厂也反射 http://www.cnblogs.com/shenfx318/archive/2007/01/16/621237.html 在我的上一篇文章(疑惑？改良？从简单工厂到工厂方法)中，详细论述了创建模式中简单工厂到工厂方法的演变过程，并试图结合工厂方法的设计以及.net中的反射机制之所长，改良出一种新型的工厂—反射工厂，这当然不是我的首创，经典的PetShop 中便有此工厂的身影。本文尝试按照前篇文章的思路，借着工厂方法到抽象工厂的演变过程而继续对抽象工厂进行改良，文章中的思想仅代表了作者当时的观点，有欠妥的地方，还请各位不吝赐教。 工厂模式 前面的文章提到了简单工厂和工厂方法其实是一码事，他们完成了将客户对产品功能的使用与创建具体产品职责的分割，不同的只不过是他们实现方式上的差异，工厂方法利用更加优雅的多态性取代了相对ugly的switch case…语句，从而很好的体现了设计原则中的OCP原则，此文章将不再强调这种实现上的差异性，而更多的强调两者之间设计思路上的共性，并将这种共性统称成为工厂模式,从而进一步与抽象工厂进行对比。 工厂的使用，选择的过程 工厂模式的使用，实际上是客户 (产品的消费者) 对于产品选择的过程，对于实现了相同功能的产品来讲，客户更加关心的是产品间的差异性，而工厂的作用则是将产品的生产过程封装，根据客户的要求直接返回客户需要的产品。注意，工厂只是隐藏了产品的生产过程，但是并没有剥夺客户选择的权利，那么客户的这个选择过程又是如何体现的呢？在简单工厂中，客户通过参数的形式告诉工厂需要什么样的产品，而在工厂方法中，客户通过对工厂的选择代替了直接对产品的选择，注意到工厂方法中一个工厂只有一个Create方法，也就是说一个工厂只负责生产一种产品，那么你选择了相应的工厂也就等同于你选择了对应的产品。就连改良后的反射工厂也没有消去对产品的选择，只不过是将这种选择外化 (外化到配置文件中，从而使得对代码的改动最小) 。可以说，正是由于产品间的差异性带给了客户选择的权利，这种权利是不应当被工厂取代的，那么工厂模式的价值又在哪里呢？答案是抽象与封装，工厂模式将由于客户的不同选择而可能导致的对已知事物的影响降到最低，途径是通过抽象产品取代具体产品，使得客户依赖于抽象 (越抽象的东西越稳定) ，同时将客户的选择封装到一处，隔离与具体产品间的依赖。 工厂模式与抽象工厂 前面说了这么多无关的，为得是做好铺垫，更加有益于对下文的理解，OK，终于该说说从工厂模式到抽象工厂的转变了，先来对比两张类图: 工厂方法(Factory Method) <img src="http://images.cnblogs.com/cnblogs_com/shenfx318/FactoryMethod3.jpg" alt="" width="506" height="186" border="0" /> 抽象工厂(Abstract Factory) 从图中我们能够看到哪些差异？ 最明显的一点就是在工厂方法的类关系图中只有一类产品，他们实现了一个统一的接口，而抽象工厂有多个类别的产品，他们分别实现了不同的功能 (多个接口) 。其次的一点差别就是工厂本身所具有的方法数量不同，这点差异其实也是由第一点所导致的，工厂需要有生产不同类别产品的功能，如果抽象工厂中的产品的功能简化到一个，也便成为了工厂方法。 引出类别的概念，类别是指具有相同功能的一类产品的总称。 再来看选择的过程，在工厂方法中，客户关心的只不过是实现同一样功能的不同产品间的差异，这是一个一维选择的过程。 1 IFactory factory = new FactoryA(); //选择了工厂即选择了产品 2 IProduct productA = factory.Create(); //工厂只有一个Create方法，只能生产一种产品 而在抽象工厂中，客户首先要考虑的是需要哪一样功能，其次要考虑才是产品间的差异。也就是说这是一个二维选择的过程。 1 IFactory factory = new FactoryA(); //选择了某个具体工厂 2 IProduct productA = factory.CreateProductA(); //工厂具有多个Create方法，这里选择了其中的一个 ...