导读
J2SE1.4以上版本号中公布了全新的I/O类库。本文将通过一些实例来简介NIO库提供的一些新特性：非堵塞I/O，字符转换，缓冲以及通道。
一. 介绍NIO
NIO包（
java.nio.*）引入了四个关键的抽象数据类型，它们共同解决传统的I/O类中的一些问题。
1． Buffer：它是包括数据且用于读写的线形表结构。当中还提供了一个特殊类用于内存映射文件的I/O操作。
2． Charset：它提供Unicode字符串影射到字节序列以及逆影射的操作。
3． Channels：包括socket，file和pipe三种管道，它实际上是双向交流的通道。
4． Selector：它将多元异步I/O操作集中到一个或多个线程中（它能够被看成是Unix中select（）函数或Win32中WaitForSingleEvent（）函数的面向对象版本号）。
二. 回想传统
在介绍NIO之前，有必要了解传统的I/O操作的方式。以网络应用为例，传统方式须要监听一个ServerSocket，接受请求的连接为其提供服务（服务通常包含了处理请求并发送响应）图一是
server的生命周期图，当中标有粗黑线条的部分表明会发生I/O堵塞。
图一
能够分析创建server的每一个详细步骤。首先创建ServerSocket
ServerSocket server=new ServerSocket（10000）；
然后接受新的连接请求
Socket newConnection=server.accept（）；
对于accept方法的调用将造成堵塞，直到ServerSocket接受到一个连接请求为止。一旦连接请求被接受，server能够读客户socket中的请求。
InputStream in = newConnection.getInputStream();
InputStreamReader reader = new InputStreamReader(in);
BufferedReader buffer = new BufferedReader(reader);
Request request = new Request();
while(!request.isComplete()) {
String line = buffer.readLine();
request.addLine(line);
}
这种操作有两个问题，首先BufferedReader类的readLine（）方法在其缓冲区未满时会造成线程堵塞，仅仅有一定数据填满了缓冲区或者客户关闭了套接字，方法才会返回。其次，它回产生大量的垃圾，BufferedReader创建了缓冲区来从客户套接字读入数据，可是相同创建了一些字符串存储这些数据。尽管BufferedReader内部提供了StringBuffer处理这一问题，可是全部的String非常快变成了垃圾须要回收。
相同的问题在发送响应代码中也存在
Response response = request.generateResponse();
OutputStream out = newConnection.getOutputStream();
InputStream in = response.getInputStream()；
int ch；
while(-1 != (ch = in.read())) {
out.write(ch);
}
newConnection.close();
类似的，读写操作被堵塞并且向流中一次写入一个字符会造成效率低下，所以应该使用缓冲区，可是一旦使用缓冲，流又会产生很多其它的垃圾。
传统的解决方法
通常在Java中处理堵塞I/O要用到线程（大量的线程）。通常是实现一个线程池用来处理请求，如图二
图二
线程使得server能够处理多个连接，可是它们也相同引发了很多问题。每一个线程拥有自己的栈空间并且占用一些CPU时间，耗费非常大，并且非常多时间是浪费在堵塞的I/O操作上，没有有效的利用CPU。
三. 新I/O
1． Buffer
传统的I/O不断的浪费对象资源（一般是String）。新I/O通过使用Buffer读写数据避免了资源浪费。Buffer对象是线性的，有序的数据集合，它依据其类别仅仅包括唯一的数据类型。
java.nio.Buffer 类描写叙述
java.nio.ByteBuffer 包括字节类型。 能够从ReadableByteChannel中读在 WritableByteChannel中写
java.nio.MappedByteBuffer 包括字节类型，直接在内存某一区域映射
java.nio.CharBuffer 包括字符类型，不能写入通道
java.nio.DoubleBuffer 包括double类型，不能写入通道
java.nio.FloatBuffer 包括float类型
java.nio.IntBuffer 包括int类型
java.nio.LongBuffer 包括long类型
java.nio.ShortBuffer 包括short类型
能够通过调用allocate(int capacity)方法或者allocateDirect(int capacity)方法分配一个Buffer。特别的，你能够创建MappedBytesBuffer通过调用FileChannel.map(int mode,long position,int size)。直接（direct）buffer在内存中分配一段连续的块并使用本地訪问方法读写数据。非直接(nondirect)buffer通过使用Java中的数组訪问代码读写数据。有时候必须使用非直接缓冲比如使用不论什么的wrap方法（如ByteBuffer.wrap(byte[])）在Java数组基础上创建buffer。
2． 字符编码
向ByteBuffer中存放数据涉及到两个问题：字节的顺序和字符转换。ByteBuffer内部通过ByteOrder类处理了字节顺序问题，可是并没有处理字符转换。其实，ByteBuffer没有提供方法读写String。
Java.nio.charset.Charset处理了字符转换问题。它通过构造CharsetEncoder和CharsetDecoder将字符序列转换成字节和逆转换。
3． 通道(Channel)
你可能注意到现有的java.io类中没有一个能够读写Buffer类型，所以NIO中提供了Channel类来读写Buffer。通道能够觉得是一种连接，能够是到特定设备，程序或者是网络的连接。通道的类等级结构图例如以下
图三
图中ReadableByteChannel和WritableByteChannel分别用于读写。
GatheringByteChannel能够从使用一次将多个Buffer中的数据写入通道，相反的，ScatteringByteChannel则能够一次将数据从通道读入多个Buffer中。你还能够设置通道使其为堵塞或非堵塞I/O操作服务。
为了使通道可以同传统I/O类相容，Channel类提供了静态方法创建Stream或Reader
4． Selector
在过去的堵塞I/O中，我们一般知道什么时候能够向stream中读或写，由于方法调用直到stream准备好时返回。可是使用非堵塞通道，我们须要一些方法来知道什么时候通道准备好了。在NIO包中，设计Selector就是为了这个目的。SelectableChannel能够注冊特定的事件，而不是在事件发生时通知应用，通道跟踪事件。然后，当应用调用Selector上的随意一个selection方法时，它查看注冊了的通道看是否有不论什么感兴趣的事件发生。图四是selector和两个已注冊的通道的样例
图四
并非全部的通道都支持全部的操作。SelectionKey类定义了全部可能的操作位，将要用两次。首先，当应用调用SelectableChannel.register(Selector sel,int op)方法注冊通道时，它将所需操作作为第二个參数传递到方法中。然后，一旦SelectionKey被选中了，SelectionKey的readyOps()方法返回全部通道支持操作的数位的和。SelectableChannel的validOps方法返回每一个通道同意的操作。注冊通道不支持的操作将引发IllegalArgumentException异常。下表列出了SelectableChannel子类所支持的操作。
ServerSocketChannel OP_ACCEPT
SocketChannel OP_CONNECT, OP_READ, OP_WRITE
DatagramChannel OP_READ, OP_WRITE
Pipe.SourceChannel OP_READ
Pipe.SinkChannel OP_WRITE
四. 举例说明
1． 简单网页内容下载
这个样例很easy，类SocketChannelReader使用SocketChannel来下载特定网页的HTML内容。
package examples.nio; import java.nio.ByteBuffer; import java.nio.channels.SocketChannel; import java.nio.charset.Charset; import java.net.InetSocketAddress; import java.io.IOException; public class SocketChannelReader{ private Charset charset=Charset.forName("UTF-8");//创建UTF-8字符集 private SocketChannel channel; public void getHTMLContent(){ try{ connect(); sendRequest(); readResponse(); }catch(IOException e){ System.err.println(e.toString()); }finally{ if(channel!=null){ try{ channel.close(); }catch(IOException e){} } } } private void connect()throws IOException{//连接到CSDN InetSocketAddress socketAddress= new InetSocketAddress("http://www.csdn.net",80/); channel=SocketChannel.open(socketAddress); //使用工厂方法open创建一个channel并将它连接到指定地址上 //相当与SocketChannel.open().connect(socketAddress);调用 } private void sendRequest()throws IOException{ channel.write(charset.encode("GET " +"/document" +"\r\n\r\n"));//发送GET请求到CSDN的文档中心 //使用channel.write方法，它须要CharByte类型的參数，使用 //Charset.encode(String)方法转换字符串。 } private void readResponse()throws IOException{//读取应答 ByteBuffer buffer=ByteBuffer.allocate(1024);//创建1024字节的缓冲 while(channel.read(buffer)!=-1){ buffer.flip();//flip方法在读缓冲区字节操作之前调用。 System.out.println(charset.decode(buffer)); //使用Charset.decode方法将字节转换为字符串 buffer.clear();//清空缓冲 } } public static void main(String [] args){ new SocketChannelReader().getHTMLContent(); } |
2． 简单的加法server和客户机
server代码
package examples.nio; import java.nio.ByteBuffer; import java.nio.IntBuffer; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.net.InetSocketAddress; import java.io.IOException; /** * SumServer.java * * * Created: Thu Nov 06 11:41:52 2003 * * @author starchu1981 * @version 1.0 */ public class SumServer { private ByteBuffer _buffer=ByteBuffer.allocate(8); private IntBuffer _intBuffer=_buffer.asIntBuffer(); private SocketChannel _clientChannel=null; private ServerSocketChannel _serverChannel=null; public void start(){ try{ openChannel(); waitForConnection(); }catch(IOException e){ System.err.println(e.toString()); } } private void openChannel()throws IOException{ _serverChannel=ServerSocketChannel.open(); _serverChannel.socket().bind(new InetSocketAddress(10000)); System.out.println("server通道已经打开"); } private void waitForConnection()throws IOException{ while(true){ _clientChannel=_serverChannel.accept(); if(_clientChannel!=null){ System.out.println("新的连接增加"); processRequest(); _clientChannel.close(); } } } private void processRequest()throws IOException{ _buffer.clear(); _clientChannel.read(_buffer); int result=_intBuffer.get(0)+_intBuffer.get(1); _buffer.flip(); _buffer.clear(); _intBuffer.put(0,result); _clientChannel.write(_buffer); } public static void main(String [] args){ new SumServer().start(); } } // SumServer 客户代码 package examples.nio; import java.nio.ByteBuffer; import java.nio.IntBuffer; import java.nio.channels.SocketChannel; import java.net.InetSocketAddress; import java.io.IOException; /** * SumClient.java * * * Created: Thu Nov 06 11:26:06 2003 * * @author starchu1981 * @version 1.0 */ public class SumClient { private ByteBuffer _buffer=ByteBuffer.allocate(8); private IntBuffer _intBuffer; private SocketChannel _channel; public SumClient() { _intBuffer=_buffer.asIntBuffer(); } // SumClient constructor public int getSum(int first,int second){ int result=0; try{ _channel=connect(); sendSumRequest(first,second); result=receiveResponse(); }catch(IOException e){System.err.println(e.toString()); }finally{ if(_channel!=null){ try{ _channel.close(); }catch(IOException e){} } } return result; } private SocketChannel connect()throws IOException{ InetSocketAddress socketAddress= new InetSocketAddress("localhost",10000); return SocketChannel.open(socketAddress); } private void sendSumRequest(int first,int second)throws IOException{ _buffer.clear(); _intBuffer.put(0,first); _intBuffer.put(1,second); _channel.write(_buffer); System.out.println("发送加法请求 "+first+"+"+second); } private int receiveResponse()throws IOException{ _buffer.clear(); _channel.read(_buffer); return _intBuffer.get(0); } public static void main(String [] args){ SumClient sumClient=new SumClient(); System.out.println("加法结果为 :"+sumClient.getSum(100,324)); } } // SumClient |
3． 非堵塞的加法server
首先在openChannel方法中增加语句
_serverChannel.configureBlocking(false);//设置成为非堵塞模式
重写WaitForConnection方法的代码例如以下，使用非堵塞方式
private void waitForConnection()throws IOException{ Selector acceptSelector = SelectorProvider.provider().openSelector(); /*在server套接字上注冊selector并设置为接受accept方法的通知。 这就告诉Selector，套接字想要在accept操作发生时被放在ready表 上，因此，同意多元非堵塞I/O发生。*/ SelectionKey acceptKey = ssc.register(acceptSelector, SelectionKey.OP_ACCEPT); int keysAdded = 0; /*select方法在不论什么上面注冊了的操作发生时返回*/ while ((keysAdded = acceptSelector.select()) > 0) { // 某客户已经准备好能够进行I/O操作了，获取其ready键集合 Set readyKeys = acceptSelector.selectedKeys(); Iterator i = readyKeys.iterator(); // 遍历ready键集合，并处理加法请求 while (i.hasNext()) { SelectionKey sk = (SelectionKey)i.next(); i.remove(); ServerSocketChannel nextReady = (ServerSocketChannel)sk.channel(); // 接受加法请求并处理它 _clientSocket = nextReady.accept().socket(); processRequest(); _clientSocket.close(); } } } |
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
内存区域
Java虚拟机在执行Java程序的过程中会把他所管理的内存划分为若干个不同的数据区域。Java虚拟机规范将JVM所管理的内存分为以下几个运行时数据区：程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区。下面详细阐述各数据区所存储的数据类型。
程序计数器（Program Counter Register）
一块较小的内存空间，它是当前线程所执行的字节码的行号指示器，字节码解释器
工作时通过改变该计数器的值来选择下一条需要执行的字节码指令，分支、跳转、循环等基础功能都要依赖它来实现。每条线程都有一个独立的的程序计数器，各线程间的计数器互不影响，因此该区域是线程私有的。
当线程在执行一个Java方法时，该计数器记录的是正在执行的虚拟机字节码指令的地址，当线程在执行的是Native方法（调用本地
操作系统方法）时，该计数器的值为空。另外，该内存区域是唯一一个在Java虚拟机规范中么有规定任何OOM（内存溢出：OutOfMemoryError）情况的区域。
Java虚拟机栈（Java Virtual Machine Stacks）
该区域也是线程私有的，它的生命周期也与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧，栈它是用于支持续虚拟机进行方法调用和方法执行的数据结构。对于执行引擎来讲，活动线程中，只有栈顶的栈帧是有效的，称为当前栈帧，这个栈帧所关联的方法称为当前方法，执行引擎所运行的所有字节码指令都只针对当前栈帧进行操作。栈帧用于存储局部变量表、操作数栈、动态链接、方法返回地址和一些额外的附加信息。在编译程序代码时，栈帧中需要多大的局部变量表、多深的操作数栈都已经完全确定了，并且写入了方法表的Code属性之中。因此，一个栈帧需要分配多少内存，不会受到程序运行期变量数据的影响，而仅仅取决于具体的虚拟机实现。
在Java虚拟机规范中，对这个区域规定了两种异常情况：
1、如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。
2、如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
这里有一点要重点说明，在多线程情况下，给每个线程的栈分配的内存越大，越容易产生内存溢出异常。操作系统为每个进程分配的内存是有限制的，虚拟机提供了参数来控制Java堆和方法区这两部分内存的最大值，忽略掉程序计数器消耗的内存（很小），以及进程本身消耗的内存，剩下的内存便给了虚拟机栈和本地方法栈，每个线程分配到的栈容量越大，可以建立的线程数量自然就越少。因此，如果是建立过多的线程导致的内存溢出，在不能减少线程数的情况下，就只能通过减少最大堆和每个线程的栈容量来换取更多的线程。当由于创建过量线程发生OOM时，会报错：java.lang.OutOfMemoryError, unable to create new native thread。
本地方法栈（Native Method Stacks）
该区域与虚拟机栈所发挥的作用非常相似，只是虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为使用到的本地操作系统（Native）方法服务。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError与OutOfMemoryError异常。
Java堆（Java Heap）
Java Heap是Java虚拟机所管理的内存中最大的一块，它是所有线程共享的一块内存区域，几乎所有的对象实例和数组都在这类分配内存。Java Heap是垃圾收集器管理的主要区域，因此很多时候也被称为“GC堆”。
根据Java虚拟机规范的规定，Java堆可以处在物理上不连续的内存空间中，只要逻辑上是连续的即可。如果在堆中没有内存可分配时，并且堆也无法扩展时，将会抛出OutOfMemoryError异常。
注意：随着JIT编译器的发展与逃逸技术逐渐成熟，所有对象都分配在堆上也逐渐变得不是那么绝对了，线程共享的Java堆中也可能划分出线程私有的分配缓冲区（TLAB）。
方法区（Method Area）
方法区也是各个线程共享的内存区域，它用于存储已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Java虚拟机规范把方法区描述为Java堆的一个逻辑部分，而且它和Java Heap一样不需要连续的内存，可以选择固定大小或可扩展，另外，虚拟机规范允许该区域可以选择不实现垃圾回收。相对而言，垃圾收集行为在这个区域比较少出现。不过，这部分区域的回收是有必要的，如果这部分区域永远不回收，那么类型就无法卸载，我们就无法加载更多的类，HotSpot的该区域有实现垃圾回收。
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
直接内存（Direct Memory）
直接内存并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，它直接从操作系统中分配，因此不受Java堆大小的限制，但是会受到本机总内存的大小及处理器寻址空间的限制，因此它也可能导致OutOfMemoryError异常出现。在JDK1.4中新引入了NIO机制，它是一种基于通道与缓冲区的新I/O方式，可以直接从操作系统中分配直接内存，即在堆外分配内存，这样能在一些场景中提高性能，因为避免了在Java堆和Native堆中来回复制数据。
当使用超过虚拟机允许的直接内存时，虚拟机会抛出OutOfMemoryError异常，由DirectMemory导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显的异常。一般来说，如果发现OOM后Dump文件很小，那就应该考虑一下，是不是这块内存发生了溢出。
内存溢出
Java堆内存溢出
public class HeapOOM { static class OOMObject { } public static void main(String[] args) { List<OOMObject> list = new ArrayList<OOMObject>(); while (true) { list.add(new OOMObject()); } } } |
运行以上代码时，可以增加运行参数-Xms20m -Xmx20m，该参数限制Java堆大小为20M，不可扩展。运行结果如下：
<span style="color: #ff0000;">Exception in thread "main" java.lang.OutOfMemoryError: Java heap space</span> at java.util.Arrays.copyOf(Arrays.java:2245) at java.util.Arrays.copyOf(Arrays.java:2219) at java.util.ArrayList.grow(ArrayList.java:242) at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216) at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208) at java.util.ArrayList.add(ArrayList.java:440) at HeapOOM.main(HeapOOM.java:17) |
可以看到，在堆内存溢出时，除了会报错java.lang.OutOfMemoryError外，还会跟着进一步提示Java heap space。
虚拟机栈和本地方法栈溢出
要让虚拟机栈内存溢出，我们可以使用递归调用：因为每次方法调用都需要向栈中压入调用信息，当栈的大小固定时，过深的递归将向栈中压入过量信息，导致
StackOverflowError： public class JavaVMStackSOF { private int stackLength = 1; public void stackLeak() { stackLength++; stackLeak(); } public static void main(String[] args) throws Throwable { JavaVMStackSOF oom = new JavaVMStackSOF(); try { oom.stackLeak(); } catch (Throwable e) { System.out.println("stack length:" + oom.stackLength); throw e; } } } |
运行以上代码，输出如下：
stack length:10828
<span style="color: #ff0000;">Exception in thread "main" java.lang.StackOverflowError</span>
at JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:10)
at JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:11)
at JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:11)
可以看到，在我的电脑上运行以上代码，最多支持的栈深度是10828层，当发生栈溢出时，会报错java.lang.StackOverflowError。
方法区溢出
方法区用于存放Class的相关信息，如类名、访问修饰符、字段描述等，对于这个区域的测试，基本思路是运行时使用CGLib产生大量的类去填充方法区，直到溢出：
public class JavaMethodAreaOOM { static class OOMObject { } public static void main(String[] args) { while( true) { Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(OOMObject. class); enhancer.setUseCache( false); enhancer.setCallback( new MethodInterceptor() { @Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { return proxy.invokeSuper(obj, args); } }); enhancer.create(); } } } |
运行时增加虚拟机参数：-XX:PermSize=10M -XX:MaxPermSize=10M，限制永久代大小为10M，最后报错为java.lang.OutOfMemoryError: PermGen space。报错信息明确说明，溢出区域为永久代。
总结
本文主要说明Java虚拟机一共分为哪几块内存区域，以及这几块内存区域是否会内存溢出，如果这些区域发生内存溢出报错如何。了解这些知识后，以后遇到内存溢出报错，我们就可以定位到具体内存区域，然后具体问题，具体分析。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
参数是按值而不是按引用传递的说明
Java 应用程序有且仅有的一种参数传递机制，即按值传递。写它是为了揭穿普遍存在的一种神话，即认为 Java 应用程序按引用传递参数，以避免因依赖“按引用传递”这一行为而导致的常见编程错误。
对此节选的某些反馈意见认为，我把这一问题搞糊涂了，或者将它完全搞错了。许多不同意我的读者用 C++ 语言作为例子。因此，在此栏目中我将使用 C++ 和 Java 应用程序进一步阐明一些事实。
要点
读完所有的评论以后，问题终于明白了，考试吧提示: 至少在一个主要问题上产生了混淆。因为对象是按引用传递的。对象确实是按引用传递的；节选与这没有冲突。节选中说所有参数都是按值 -- 另一个参数 -- 传递的。下面的说法是正确的：在 Java 应用程序中永远不会传递对象，而只传递对象引用。因此是按引用传递对象。但重要的是要区分参数是如何传递的，这才是该节选的意图。Java 应用程序按引用传递对象这一事实并不意味着 Java 应用程序按引用传递参数。参数可以是对象引用，而 Java 应用程序是按值传递对象引用的。
C++ 和 Java 应用程序中的参数传递
Java 应用程序中的变量可以为以下两种类型之一：引用类型或基本类型。当作为参数传递给一个方法时，处理这两种类型的方式是相同的。两种类型都是按值传递的；没有一种按引用传递。这是一个重要特性，正如随后的代码示例所示的那样。
在继续讨论之前，定义按值传递和按引用传递这两个术语是重要的。按值传递意味着当将一个参数传递给一个函数时，函数接收的是原始值的一个副本。因此，如果函数修改了该参数，仅改变副本，而原始值保持不变。按引用传递意味着当将一个参数传递给一个函数时，函数接收的是原始值的内存地址，而不是值的副本。因此，如果函数修改了该参数，调用代码中的原始值也随之改变。
上面的这些是很重要的，请大家注意以下几点结论，这些都是我认为的上面的文章中的精华和最终的结论： 1、对象是按引用传递的
2、Java 应用程序有且仅有的一种参数传递机制，即按值传递
3、按值传递意味着当将一个参数传递给一个函数时，函数接收的是原始值的一个副本
4、按引用传递意味着当将一个参数传递给一个函数时，函数接收的是原始值的内存地址，而不是值的副本
首先考试吧来看看第一点：对象是按引用传递的
确实，这一点我想大家没有任何疑问，例如：
class Test01
{
public static void main(String[] args)
{
StringBuffer s= new StringBuffer("good");
StringBuffer s2=s;
s2.append(" afternoon.");
System.out.println(s);
}
}
对象s和s2指向的是内存中的同一个地址因此指向的也是同一个对象。
如何解释“对象是按引用传递的”的呢？
这里的意思是进行对象赋值操作是传递的是对象的引用，因此对象是按引用传递的，有问题吗？
程序运行的输出是：
good afternoon.
这说明s2和s是同一个对象。
这里有一点要澄清的是，这里的传对象其实也是传值，因为对象就是一个指针，这个赋值是指针之间的赋值，因此在java中就将它说成了传引用。（引用是什么？不就是地址吗？地址是什么，不过就是一个整数值）
再看看下面的例子：
class Test02
{
public static void main(String[] args)
{
int i=5;
int i2=i;
i2=6;
System.out.println(i);
}
}
程序的结果是什么？5！！！
这说明什么，原始数据类型是按值传递的，这个按值传递也是指的是进行赋值时的行为。
下一个问题：Java 应用程序有且仅有的一种参数传递机制，即按值传递
class Test03 { public static void main(String[] args) { StringBuffer s= new StringBuffer("good"); StringBuffer s2=new StringBuffer("bad"); test(s,s2); System.out.println(s);//9 System.out.println(s2);//10 } static void test(StringBuffer s,StringBuffer s2) { System.out.println(s);//1 System.out.println(s2);//2 s2=s;//3 s=new StringBuffer("new");//4 System.out.println(s);//5 System.out.println(s2);//6 s.append("hah");//7 s2.append("hah");//8 } } |
程序的输出是：
good
bad
new
good
goodhah
bad
考试吧提示: 为什么输出是这样的？
这里需要强调的是“参数传递机制”，它是与赋值语句时的传递机制的不同。
我们看到1,2处的输出与我们的预计是完全匹配的
3将s2指向s，4将s指向一个新的对象
因此5的输出打印的是新创建的对象的内容，而6打印的原来的s的内容
7和8两个地方修改对象内容，但是9和10的输出为什么是那样的呢？
Java 应用程序有且仅有的一种参数传递机制，即按值传递。
至此，我想总结一下我对这个问题的最后的看法和我认为可以帮助大家理解的一种方法：
我们可以将java中的对象理解为c/c++中的指针
例如在c/c++中：
int *p;
print(p);//1
*p=5;
print(*p);//2
1打印的结果是什么，一个16进制的地址，2打印的结果是什么?5，也就是指针指向的内容。
即使在c/c++中，这个指针其实也是一个32位的整数，我们可以理解我一个long型的值。
而在java中一个对象s是什么，同样也是一个指针，也是一个int型的整数（对于JVM而言），我们在直接使用（即s2=s这样的情况，但是对于System.out.print(s)这种情况例外，因为它实际上被晃猄ystem.out.print(s.toString())）对象时它是一个int的整数，这个可以同时解释赋值的传引用和传参数时的传值（在这两种情况下都是直接使用），而我们在s.XXX这样的情况下时s其实就是c/c++中的*s这样的使用了。这种在不同的使用情况下出现不同的结果是java为我们做的一种简化，但是对于c/c++程序员可能是一种误导。java中有很多中这种根据上下文进行自动识别和处理的情况，下面是一个有点极端的情况：
class t { public static String t="t"; public static void main(String[] args) { t t =new t(); t.t(); } static void t() { System.out.println(t); } } |
（关于根据上下文自动识别的内容，有兴趣的人以后可以看看我们翻译的《java规则》）
1、对象是按引用传递的
2、Java 应用程序有且仅有的一种参数传递机制，即按值传递
3、按值传递意味着当将一个参数传递给一个函数时，函数接收的是原始值的一个副本
4、按引用传递意味着当将一个参数传递给一个函数时，函数接收的是原始值的内存地址，而不是值的副本
三句话总结一下：
1.对象就是传引用
2.原始类型就是传值
3.String类型因为没有提供自身修改的函数，每次操作都是新生成一个String对象，所以要特殊对待。可以认为是传值。
==========================================================================
public class Test03 { public static void stringUpd(String str) { str = str.replace("j", "l"); System.out.println(str); } public static void stringBufferUpd(StringBuffer bf) { bf.append("c"); System.out.println(bf); } public static void main(String[] args) { /** * 對於基本類型和字符串（特殊）是傳值 * * 輸出lava,java */ String s1 = new String("java"); stringUpd(s1); System.out.println(s1); /** * 對於對象而言，傳的是引用，而引用指向的是同一個對象 * * 輸出javac,javac */ StringBuffer bb = new StringBuffer("java"); stringBufferUpd(bb); System.out.println(bb); } } |
解析：就像光到底是波还是粒子的问题一样众说纷纭，对于Java参数是传值还是传引用的问题，也有很多错误的理解和认识。我们首先要搞清楚一点就是：不管Java参数的类型是什么，一律传递参数的副本。对此，thinking in Java一书给出的经典解释是When you’re passing primitives into a method, you get a distinct copy of the primitive. When you’re passing a reference into a method, you get a copy of the reference.(如果Java是传值，那么传递的是值的副本;如果Java是传引用，那么传递的是引用的副本。)
在Java中，变量分为以下两类：
① 对于基本类型变量(int、long、double、float、byte、boolean、char)，Java是传值的副本。(这里Java和C++相同)
② 对于一切对象型变量，Java都是传引用的副本。其实传引用副本的实质就是复制指向地址的指针，只不过Java不像C++中有显著的*和&符号。(这里Java和C++不同，在C++中，当参数是引用类型时，传递的是真实引用而不是引用副本)
需要注意的是：String类型也是对象型变量，所以它必然是传引用副本。不要因为String在Java里面非常易于使用，而且不需要new，就被蒙蔽而把String当做基本变量类型。只不过String是一个非可变类，使得其传值还是传引用显得没什么区别。
对基本类型而言，传值就是把自己复制一份传递，即使自己的副本变了，自己也不变。而对于对象类型而言，它传的引用副本(类似于C++中的指针)指向自己的地址，而不是自己实际值的副本。为什么要这么做呢？因为对象类型是放在堆里的，一方面，速度相对于基本类型比较慢，另一方面，对象类型本身比较大，如果采用重新复制对象值的办法，浪费内存且速度又慢。就像你要张三(张三相当于函数)打开仓库并检查库里面的货物(仓库相当于地址)，有必要新建一座仓库(并放入相同货物)给张三么? 没有必要，你只需要把钥匙(引用)复制一把寄给张三就可以了，张三会拿备用钥匙(引用副本，但是有时效性，函数结束，钥匙销毁)打开仓库。
在这里提一下，很多经典书籍包括thinking in Java都是这样解释的：“不管是基本类型还是对象类型，都是传值。”这种说法也不能算错，因为它们把引用副本也当做是一种“值”。但是笔者认为：传值和传引用本来就是两个不同的内容，没必要把两者弄在一起，弄在一起反而更不易理解。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
这些年我曾和很多
程序员一起
工作，他们之中的一些人非常厉害，而另一些人显得平庸。不久前因为和一些技术非常熟练的程序员工作感觉很愉快，我花了一些时间在考虑我佩服他们什么呢？什么原因让优秀的程序员那么优秀，糟糕的程序员那么糟糕？简而言之，什么原因成就了一位优秀的程序员呢？
根据我的经验，成为一个优秀程序员同年龄，教育程度，还有和你赚多少钱没有任何关系。关键在于你的做法，更深入地说，就是你的想法。我注意到我所钦佩的程序员都有一些相似习惯。不是他们所选语言的知识，也不是对数据结构和算法的深入理解，甚至不是多年的工作经验。而是他们的沟通方式，他们管理自己的方式，以及以他们精湛技术水平编程演讲的方式。
当然成为一个优秀的程序员还要具备更多特质，我也不能单单依靠是否存在（或者缺少）这些特质来评判一个程序员。但是我知道当我看见它，当我看见一个程序员具备这些特质的时候，我认为，“这个人真的知道他们正在做什么”。
他们做调查研究
不论你怎么称呼它，大多数可能会遇到的编程问题已经以某种形式解决，传道书早就记载着世界上本来就没有什么新鲜事。优秀的程序员在解决问题之前知道通过GitHub图书馆、网络博客，或者通过与经验丰富的程序员交流等形式来做调查研究。
我见过甚至是优秀的程序员可以快速找出解决方案，但是和我一起工作过的糟糕的程序员从来不求助于他人，结果做了大量的重复工作或者错误地解决问题，不幸的是，后来他们终将为自己犯下的错误付出了代价。
他们阅读错误信息（并按照它们行事）
这包括解析堆栈路径信息。是的，这是一件非常不幸的事情。但是如果你不愿意这么做的话，怎么才能知道哪里错了呢？我知道的高效程序员是不会害怕深究问题的。低效的程序员看见有错误，但就是不愿意甚至是去读这些错误信息。（这听起来很可笑，但你会惊讶我遇到它的频率）
更进一步地说，优秀的程序员发现问题马上就解决它。读错误信息对他们来说仅仅是个开始，他们渴望深究问题并查出问题的根源。他们不喜欢推卸责任，而是愿意查找解决问题的方案，问题在他们这里止步。
他们去看源代码
文档、
测试、团队，这些都会说谎。尽管不是故意的，但是如果你想确切地知道事情是怎么回事，你必须自己亲自看源代码。
如果它不是你最擅长的语言，你也不要害怕。如果你是一个
Ruby的程序员，你怀疑在Ruby的C语言库中有个错误，破解打开看看。是的，你可能拿不到源代码，但是谁知道呢？你只是可能而已，你有更好的机会，总比你根本不去尝试好吧。
不幸的是，如果你处在一个封闭源代码的环境中，这会变得非常难，但道理是不变的。糟糕的程序员对于查看源代码没有丝毫的兴趣，结果问题困扰他们时间，要比愿意看源代码的时间长得多。
They just do it
优秀的程序员趋向于主动去做。他们的内心有着难以控制的冲动，当他们确定问题或者发现新的需求时他们立刻会实现解决方案，有时过早有时太过激进。但是他们对问题本能的反应是正面解决问题。
有时这会令人很烦恼，但是他们的热情是他们做好事情的一个重要部分。一些人可能拖延时间回避问题或者等待问题自己能够消失，然而优秀的程序员一开始就解决它。简而言之（或者显而易见），如果你看见有人兴致勃勃地查找问题并在解决，很可能你的手下有位优秀的程序员。
他们避免危机
这通常是糟糕程序员的特点：他们轻易地从一个人为危机跳到另一个人为危机，在没有真正理解一个问题之前就进入到下一个问题。他们会把责任归咎于程序的错误，然后花费大把的时间调试已经运行良好的代码。他们让情感占据主动，相信直觉，而不是仔细严谨的分析。
如果你匆匆忙忙地解决一个问题，甚至视每一个问题为震惊世界的灾难。你很可能犯错误或者没有解决潜在的问题。优秀的程序员花时间去了解发生了什么错误，哪怕灾难来临的时候；但更重要的是，他们对待平常的问题像是要解决的重要问题，因此他们更准确地解决更多的问题，并且这样做没有提高团队的紧张程度。
他们善于沟通交流
说到底，编程是一种形式的沟通交流。写代码和写散文创作一样，能够简洁地表达你的想法很重要。我发现那些可以写简洁邮件，优雅的状态报告，或者甚至只是一个有效的备忘录的程序员也将会是优秀的程序员。
这能应用在写代码还有英语上。用圆括号、括号和单个字母的函数写出一行代码当然是有可能的，但是如果没有人理解它，有什么意义呢。优秀的程序员会花时间以各种渠道交流他们的想法。
他们激情四射
我认为这可能是优秀的程序员最重要的方面（也许这点也适用于除计算机科学领域的其它领域）
如果你真的在乎你所做的事情，如果不把它当成工作，当作一个业余爱好、兴趣或一件很有吸引力的事情，那么在该领域你比其他人更有优势。优秀的程序员一直不断编程。普通程序员一天工作八小时，并且没有业余项目，也没兴趣回馈社区。他们不会不断地尝试新方法，而只是为了看看它们是如何运行而执着于编程语言。
当我看见一个程序员利用周末的时间做自己喜欢的项目时，参与创作他们每天能用到的工具时，执着于新的有意义的事情时：那个时候我确信我眼前的是一个令人惊奇的人。最后，优秀的程序员视他们的职业不仅仅是赚钱的途径，更是让生活变得有些不同的方法。我认为那就是成就最优秀程序员的真正原因。对于他们来说，编写代码是改变世界的一种方法，也是我非常尊敬崇拜他们的原因。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“我们公司最大的问题是项目不能按时完成，总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈中，又引出他一连串在软件研发管理中的遇到的问题，包括：
. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？
. 重构会造成回退，怎样避免？
. 有些开发人员水平相对不高，如何保证他们的代码质量？
. 软件研发到底需不需要文档？
. 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？
. 当有开发人员在开发过程中遇到难题，
工作无法继续，因而拖延进度，怎么解决？
. 如何提高开发人员的主观能动性？
其实，每个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。
1. 项目不能按时完成，总要一拖再拖，怎么改变？
找解决办法前，当然要先知道问题为什么会出现。这位总经理说：“总会不断地有需求要改变和新需求提出来，使原来的开发计划不得不延长。”原来如此。知道根源，当然解决办法也就有了，那就是“
敏捷”。敏捷开发因其迭代（Iterative）和增量（Incremental）的思想与实践，正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念，特别是Scrum的框架后，总经理也表示了对“敏捷”的认同。
其实仔细想想，这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间，往往由高级管理层根据市场情况决策和确定。在很多软件企业中，这些决策者在决策时往往忽略了一个重要的参数，那就是团队的生产率（Velocity）。生产率需要量化，而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。Scrum创始人之一的Jeff Sutherland说，他在一个风险投资团队做敏捷教练时，团队中的资深合伙人会向所有的待投资企业问同一个问题：“你们是否清楚团队的生产率？”而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期，就首先要弄清楚自己的软件生产率。
2. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？
这可能是很多
软件开发工程师都有过的体验，在接手别人的代码时，看不懂、无法加新功能，读代码读的头疼。这说明什么？排除接手人个人水平的因素，这说明旧代码可读性、可扩展性比较差。怎么办？这时，也许重构是一种两全其美的办法。接手人重构代码，既能改善旧代码的可读性和可扩展性，又不至于因重写代码带来的时间上的风险。
从接手人心理的角度看，重构还有一个好的副作用，就是代码重构之后，接手人觉得那些原来的“烂”代码被修改成为自己引以自豪的新成就。《Scrum敏捷软件开发》的作者Mike Cohn写到过：“我的女儿们画了一幅特别令人赞叹的杰作后，她们会将它从学校带回家，并想把它展示在一个明显的位置，也就是冰箱上面。有一天，在工作中，我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西，所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪，可以骄傲地将它和孩子的艺术品一样展示在冰箱上，那不是很好吗？”所以这个积极的促进作用，将使得接手人感觉修改的代码是自己的了，而且期望能够找到更多的可以重构的东西。
3. 重构会造成回退，怎样避免？
重构确实很容易造成回退（Regression）。这时，重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加
单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但我们至少要在重构前，增加对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循以下的原则（见《重构》第4章：构筑测试体系）：
- 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，所以不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。
- 考虑可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌”，纵容你心智中比较促狭的那一部分，积极思考如何破坏代码。
- 当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。
- 不要因为“测试无法捕捉所有
Bug”，就不撰写测试代码，因为测试的确可以捕捉到大多数Bug。
- “花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。因为当测试数量达到一定程度之后，测试效益就会呈现递减态势，而非持续递增。
说到《重构》这本书，其实在每个重构方法中都有“作法（Mechanics）”一段，在重构的实践中按照上面所述的步骤进行是比较稳妥的，同时也能避免很多不经意间制造的回退出现。4. 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？
如果每个开发人员都是积极主动的，Code Review的作用能落到实处。但如果不是呢？团队管理者需要一些手段促使其有效地进行Code Review。首先，我们采用的Code Review有2种形式，一是Over-the-shoulder，也就是2个人座在一起，一个人讲，另一个人审查。二是用工具Code Collaborator来进行。无论哪种形式，在提交代码时，必须注明关于审查的信息，比如：审查者（Reviewer）的名字或审查号（Review ID，Code Collaborator自动生成），每天由一名专职人员来检查Checklist中的每一条，看是否有人漏写这些信息，如果发现会提醒提交的人补上。另外，某段提交的代码出问题，提交者和审查者都要一起来解决出现的问题，以最大限度避免审查过程敷衍了事。
博主Inovy在某个评论说的很形象：“木（没）有赏罚的制度，就是带到厕所的报纸，看完就可以用来擦屁股了。”没有奖惩制度作保证，当然上面的要求没有什么效力。所以，当有人经常不审查就提交，或审查时不负责任，它的绩效评定就会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人会因为多次被查出没有做Code Review就提交代码，而到年底加薪时比别人少涨500块钱。
5. 软件研发到底需不需要文档？
软件研发需要文档的起原可能有2种，一是比较原始的，需要文档是为了当开发人员离职后，企业需要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业遵从ISO9001质量管理体系或CMMI。
对于第一种，根源可能来自于两个方面：
- 原开发人员设计编码水平不高，其代码可读性较差。
- 设计思想和代码只有一个人了解，此人一旦离职，无人知道其细节。
在编码前写一些简单的设计文档，有助于理清思路，尤其是辅以一些UML图，在交流时也是有好处的。但同时，我们也应该提高开发人员的编码水平增加其代码的可读性，比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、增加和改进注释等等，以减少不必要的文档。另外推行代码的集体所有权（Collective Ownership），避免某些代码只被一个人了解，这样可以减少以此为目的而编写的文档。
对于第二种，情况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是，它们的宗旨是一致的，即：构建高质量的产品。
对于敏捷，使用手写用户故事来记录需求和优先级的方法，以及在白板上写画的非正式设计，是不能通过ISO9001的审核的，但当把它们复印、拍照、增加序号、保存后，可以通过审核。每次都是成功的Daily Build和Auto Test报告无法证明它们是否真正被执行并真正成功，所以不能通过ISO9001的审核。但添加一个断言失败（类似assert(false)的断言）的测试后，则可以通过审核。
CMMI与敏捷也是互补的，前者告诉组织在总体条款上做什么，但是没有说如何去做，后者是一套最佳实践。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了最终目标是改进他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或产品。
所以敏捷开发在过程中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不矛盾。在实践中，我们可以按以下方法做，在实现SCRUM的同时，符合审核和评估的要求：
- 制作格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片同样有效。
- 将监管需要的文档工作也放入Backlog。除了可以确保它们不被忘记，还能使监管要求的成本是可见的。
- 使用检查列表，以向审核员或评估员证明活动已执行。团队对“完成”的定义(Definition of “Done”)可以很容易转变为一份检查列表。
- 使用敏捷项目管理工具。它其实就是开发程序和记录的电子呈现方式。
总而言之，软件研发需要文档（但文档的形式可以是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，保存在Quality Center中的测试用例也是文档），同时我们只需写够用的文档。
6. 当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？
这也是个常遇到的问题。如果管理者对于某个工程师的具体问题进行指导，就会陷入过度微观管理的境地。我们需要找到宏观解决办法。一，我们基于Scrum的“团队有共同的目标”这一规则，利用前面提到的集体所有权，当出现这些问题时，用团队中所有可以使用的力量来帮助其摆脱困境，而不是任其他人袖手旁观。当然这里会牵扯到绩效评定的问题，比如：提供帮助的人会觉得，他的帮助无助于自己绩效评定的提高，为什么要提供帮助。这需要人力资源部门在使用Scrum开发的团队的绩效评估中，尽量消除那些倾向个人的因素，还要包含团队协作的因素，广泛听取个方面的意见，更频繁地评估绩效等等。
二，即使动用所有可以使用的力量，如果某个难题真的无法逾越，为了减少不能按时交付的风险，产品负责人应当站出来，并有所作为。要么重新评估Backlog的优先级，使无法继续的Backlog迟一点交付，先做一些相对较低优先级的Backlog，以保证整体交付时间不至于延长；要么减少部分功能，给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率下降，产品负责人必须作出取舍。
7. 有些开发人员水平相对不高，如何保证他们的代码质量？
当然首先让较有经验的人Review其要提交的代码，这几乎是所有管理者会做的事。除此之外，管理者有责任帮助这些人（也包括水平较高的人）提高水平，他们可以看一些书，上网看资料，读别人的代码等等，途经还是很多的。但问题是你如何去衡量其是否真正有所收获。我们的经验是，在每年大约3月份为每个工程师制定整个年度的目标，每个人的目标包括产品上的，技术上的，个人能力上的等4到5项。半年后和一年后，要做两次Performance Review，目标是否实现，也会跟绩效评定挂钩。我们在制定目标时，遵循SMART原则，即：
Specific（明确的）：目标应该按照明确的结果和成效表述。
Measurable（可衡量的）：目标的完成情况应该可以衡量和验证。
Aligned（结盟的）：目标应该与公司的商业策略保持一致。
Realistic（现实的）：目标虽然应具挑战性，但更应该能在给定的条件和环境下实现。
Time-Bound（有时限的）：目标应该包括一个实现的具体时间。
比如：某个人制定了“初步掌握本地化技术”的目标，他要确定实现时间，要描述学习的途经和步骤，要通过将技术施加到公司现有的产品中，为公司产品的本地化/国际化/全球化作一些探索，并制作Presentation给团队演示他的成果，并准备回答其他人提出的问题。团队还为了配合其实现目标，组织Tech Talk的活动，供大家分享每个人的学习成果。通过这些手段，提高开发人员的自学兴趣，并逐步提高开发人员的技术水平。
8. 如何提高开发人员的主观能动性？
提高开发人员的主观能动性，少不了激励机制。不能让开发人员感到，5年以后的他和现在比不会有什么进步。你要让他感到他所从事的是一个职业（Career），而不只是一份工作（Job）。否则，他们是不会主动投入到工作中的。我们的经验是提供一套职业发展的框架。框架制定了2类发展道路，管理类（Managerial Path）和技术类（Technical Path），6个职业级别（1-3级是Entry/Associate，Intermediate，Senior。4级管理类是Manager/Senior Manager，技术类是Principal/Senior Principal。5级管理类是Director/Senior Director，技术类是Fellow/Architect。6级是Executive Management）。每个级别都有13个方面的具体要求，包括：范围（Scope）、跨职能（Cross Functional）、层次（Level）、知识（Knowledge）、指导（Guidance）、问题解决（Problem Solving）、递交成果（Delivering Result）、责任感（Responsbility）、导师（Mentoring）、交流（Communication）、自学（Self-Learning），运作监督（Operational Oversight），客户响应（Customer Responsiveness）。每年有2次提高级别的机会，开发人员一旦具备了升级的条件，他的Supervisor将会提出申请，一旦批准，他的头衔随之提高，薪水也会有相对较大提高。从而使每个开发人员觉得“有奔头”，自然他们的主观能动性也就提高了。
上面的“套路”涉及了软件研发团队管理中的研发过程、技术实践、文档管理、激励机制等一些方面。但只是九牛一毛，研发团队管理涵盖的内容还有很多很多，还需要管理者在不断探索和实践的道路上学习和掌握。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
曾有人问过我，“管理者什么的，跟开发人员到底有什么区别？”这两个角色都是我经历过的，但我仍花了一点时间来考虑。这个问题真的蛮重要的。
编程是从我六岁就开始的消遣。那时我写了第一个程序：从我爸爸的书里照抄了一段游戏的源代码，随即就着了迷，并且一直未曾放弃，直到编程成了我的事业。多年来，在我解决了各种有趣的或者复杂的编程问题之后，我觉得是时候去迎接新的挑战了。
但是转行就意味着放弃，放弃我多年来磨练出来的专业技能。然而，经过一番挣扎与向专业导师咨询之后，我毅然决然的跨出了这一步。
现在，干了三年半的管理，我终于有资格来回答这个问题了。管理者和开发人员最大的区别就在于衡量成功的标准不同。
具体来说:
(一) 你的成功会更琐碎
当我还是一个程序员的时候，每天来上班脑子里都会有一个
工作计划，通常这天结束时，我都能完成好这个计划。这种感觉就像是每一天我都在进步。
而作为一个经理，常常在回家的时候，都不知道我那天到底干了啥。并不是我什么事都没做，只是实在没有可供衡量的结果。
身为管理者，任务之一就是帮助工程师去做改变，但改变不会是一朝一夕可以完成的，需要时间和关注。
·你努力去实现的变化，可能模棱两可并且很难有清晰的定义。
·要认识到需要改变，这件事本身也可能很难。
·工程师们很难抛弃旧的习惯，需要不断的提醒他们。要改变他们的思维定势，是一件有挑战性的而且不轻松的事。
在 New Relic，我们每季度都会举办一个定期检查，用于提供一个反馈的渠道，让工作的重点放在长期的目标上。有些季度的发展可能突飞猛进，但大多数时候，会有的只是还叫不错的进步。
当团队人员真正出现大的变化时，就需要管理者不断的引导。我们经常使用的工具叫做“regular info-bits（定期的信息交流）”。具体做法是，工程师把他们工作上的进展用简短的 email 发给管理者。Email 的主题通常与专业发展，团队合作，项目更新，沟通交流和工作与
生活的平衡有关。这个过程有助于他们更加系统的去思考问题，你也可以通过这些信息，获悉他们的成长。
这种做法会需要很长的时间才能看到结果，但是最终可以看到你团队的成员们建立了自信并且成长良好，你会觉得一切辛苦没有白费。
（二）你的成功有战略上的影响
好的开发者可以对企业造成巨大的长期的影响，好的经理会引导整个团队的成功。
工程上的问题常常不是黑就是白。但是人的问题，几乎总是模棱两可的。即使你知道你要解决的问题是什么，解决的方法却并不是总是那么清楚。过去你用这个方法解决了这个人的问题，不代表你就可以用它解决现在的问题。人类行为这个东西实在是有太多的变量了。
要建立一个合作无间的团队，就有一系列的挑战：
·团队的建设并不是把一个个明星成员拼凑起来这么简单。
·一个有凝聚力的团队需要充分理解每个人的长处和短处。
·团队不会是一成不变的，每当有人加入或者离开，都需要重新磨合。
作为经理，你的工作是确保你的团队尽可能的高效的运行。但你不能指望稍有变动，就来一次大刀阔斧的革新，不能指望流程上动辄就做彻底的改变。有效的管理者需要：
·不断的评估你的团队需要什么帮助。
·注意，这个需求对于不同的工作和不同的团队可能是不一样的。
·使用和发明正确的工具来支持你的团队。
这个关键是逐渐的变化，不断的观测，而后不断的做出改进。例如，如果你发现你的团队没能得到足够力度的支持，首先找到办法使局面不要那么混乱，而后再寻求工具来优化你的团队。和你的小伙伴们一起努力克服困难，先选择重要的问题来处理，然后回头检查这个变动是否得当。
（三）你的成功往往就是帮助别人获得成功
在 New Relic，我们相信 Invisible Manager（隐形的经理）这个理念。这意味着我们在幕后工作，让工程师站在聚光灯下，突出他们的成功。我们确信工程师应该获得荣誉，这是他们应得的。所以 New Relic 的新功能推介会，我们鼓励让团队成员站在公众面前去介绍产品，而不是产品经理或工程经理。
大多数人管理者之前都是成功的工程师。而作为一个经理，会产生更大的影响，不仅在生意上，也在员工的生活里。许多管理者会发现，帮助别人也是帮助自己成长。
先管理好你自己
对于有工程背景的我来说，专注于手头上的问题比什么都重要。在我心里总是有一个完整的计划，涵盖了团队所需要的一切：成长，动态，质量，支持，产品交付，会议，博客发表等等。我会有一个清晰的愿景：我的团队在未来一年里要成为什么样子。这有助于我做出日常的每一个决定，而最终走向我们长期的目标。
要管理好一个团队需要大量的工作。但它也带来了大量的喜悦和自豪。作为经理你能做的最好的事情就是思考。一个月一次，找一个安静的空间，去想想你团队里的每个人，去看看旧的邮件和项目报告。你会发现你的影响力，不仅加诸于你的产品，还影响了你团队里的人。这就是成功的真正标准。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
1. 你的项目每天都在加快节奏，
2.你的客户变得越来越不耐烦，
4.管理项目的关键驱动因素，约束和浮动因素；
5.确定产品的发布条件；
6.制定项目风险列表；
7.确定当前项目最重要的因素；
8.拒绝镀金，满足要求，能够使用就是最好的项目承诺。
9.日期等于承诺；
10.好的
项目管理工具，好的项目源代码管理，好的软件缺陷跟踪工具；
11.提升人际交往技能；
12.提升功能性技能；
13.提升专业领域性专业知识技能；
14.提升工具和技术的专业技能；
15.首先实现具有最高价值的功能；
16.多几只眼睛盯着产品；
17.确定产品的关键流程，并能跑通；
18.每日站立会议，一对一会议，通过可见的方式管理进度，每周获取和报告进度情况。
19.从一开始，就要做一个功能是一个功能，不能形成技术债务；
20.学会对多任务的情况说不。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
软件开发难，恐怕大家都觉得最难的是搞清楚需求；但是其实更难的是管理需求。今天在北京.NET俱乐部上又有人提出了这样的问题，主要的难点是他的开发团队是为了自己的领导们服务的，几个领导都有自己的想法，而且不停的在开发过程中提各种个样的问题；开发进度无法保证，开发的结果总是满足不了要求……
其实这样的问题大家都遇到过，而对于普通的开发人员来说我们往往不去关心，认为这是项目经理的事情，但是其实不然，这样的问题涉及软件开发的各个环节，就算你是出于最底层的开发人员，一样需要控制项目经理交给你的任务。其实这里最重需要把握的一点就是：把任务控制在你能控制的范围之内。总结一下，我的经验如下：
第一：无论你的客户是谁，我们永远需要一个中介来接受需求；你首先需要和客户有个协议，需要他们制定某一个人来提所有的需求，这个人不需要是很高职位的人，而且往往最好的选择是中层的技术管理人员；用户的所有需求必须通过这个人的认可，就算是对方老总提出的要求，如果没有这个人的认可我们也不执行。这点非常重要，可是替我们减少许多麻烦。
第二：无论是什么样的软件开发过程理论现在都承认一个问题，那就是软件开发需要迭代。而且我们一定要面对一个现实，就是软件开发的过程是在不断的变化中寻找平衡的过程，我们的需求永远不会结束，我们的软件永远都在被修改；修改不是坏事，但是我们必须要保证在一定的时候可以拿出成果。
所以，控制迭代的增量就是非常重要的。一般我们公司的做法是，以两周为一个周期最为一个Release，一旦这个Release开始以后，任何用户的新需求就都需要放到后面的Release；我们不会决绝客户的需求，但是我们必须管理我们可以承受的进度。这样做的最大好处在于，在两周的时间内，我们一定可以为客户提供一个更好的版本，这可能不是客户现在心目中的最终结果（因为很多新需求都在后面的Release中），但是我们至少完成了我们在两周前所承诺的结果，客户得到他们想要的东西（当然不是全部），我们也可以很明确的告诉客户，我们完成什么样的需求。
而且在这样一个迭代的过程中，我们会发现很多需求中的不完善之处，每两周的时间我们都可以针对开发方向作相应调整。最终的结果是保证了客户的满意度，同时也保证了产品的按期交付。
在这里，我们需要明确的区分修改bug的需求和新功能的需求，bug应该是那些对软件主要功能造成决定性影响的缺陷，这些东西无论是我们开发人员自己发现的还是客户反馈的，都必须在当前的Release处理完；而新需求则必须放到后面的Release中去。明确区分这两种不同需求对软件项目的成功起到决定性作用。
第三：我们需要学会管理客户。可能有人觉得我在胡扯，客户怎么可能被管理，他们是上帝啊？？！！其实上帝也是人，而且是通事理的人。我们对客户永远不应该是100%的服从，正确的方式是控制用户对开发进度的期望值，尽量使他们一致。当然有些时候我们需要更强硬一点点，比如我就经常很直接的告诉我的老板，这个需求属于新功能，必须放到后面的Release中去。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
为什么
cmmi建议
需求管理在2级实施、而需求开发在3级实施呢？以前看cmmi的时候对这个是有疑问的，但是当时问了其他人也没有人很清楚，也就睁一眼闭一眼了。这次培训后，我从“成熟的过程有利于新技术的引入”的思想中得到一些启发，我觉得是不是cmmi认为，只有把需求管理做好了，做到了对需求管理理念的理解和认同，继而形成了好的习惯之后，需求开发作为一种新的技术，是相关管理人员在了解了自己的需求现状（有度量和分析）后，很朴素的和必然的要考虑的问题就是“如何把需求做得更好？”，相应的自然的就回去寻求如何“开发好的需求”。不知道，我这么理解对不对？
你的思路是对的。规范的项目过程能力，有助技术的提高，需求开发也是一样。我们需要明白哪方面的规范，可以帮助需求开发的提高。你能够看得通，可喜可贺！
但是你“睁一眼闭一眼”的态度就非常不好了。
问题的答案早就在CMMI的描述里。当然，在二级的时候，我们也有需求开发的，否则项目就不可能有交付产品。但是很多时候，我们的需求做的不够规范，没有专员负责，需求的内容，往往是不同的开发人员补充自己的任务部分，需求不能一致、不能满足客户，质量不能提高。
那么，如何才能提高需求质量？CMMI的需求管理要求：1）需求是项目与客户的了解一致、项目按着需求开展活动，以实现需求为目标。2）一个真心这样做的项目，它非得到客户真正的需求不可。开始的时候，我们的技巧未必可以达到这一点，真正明白客户的需求。但是如果我们接受以客户为中心，极力争取客户满意，我们就会不断地找方法把抽取需求的方法加以完善。这就是第三级专心要做的。但是基础，就是第二级的“项目就是要实现客户满意的需求”这个概念上的。你应该留意到，我们的项目还没有建立这个强烈的意愿，要按需求开展项目活动，所以我们连建立系统工程师团队都不愿意好好地做。3）要实现需求，就需要需求跟踪，其意义在于确保所有需求到不多不少地得到实现。我们就需要盯着需求的变更，否则我们的
工作就不是真正实现了最终版本的需求了。这一步是保证需求得到忠实实现必要的举措。
以上各点，都是CMMI二级要求的。就是说，我们二级的时候，是有需求的，但是不规范，因为我们还不了解需求的意义。这就是我说的：“我们还不尊重需求”。当项目还不尊重需求的时候，需求是提高不了的。这里“需求管理”里面的”管理“，不单单是一般的管理任务而已，它是通过这些任务，表达一个目标，这个 “需求管理”，更像是“需求意识”。就是说，知道需求的意义，重要性，与项目的关系，等等之后，必然采取的举措。CMMI列出这些举措，其实是要求项目建立需求意识。
其实，这里的“管理”可以有两个含义。字面上，他就是有一些“需求”，管理，就是如何处理它。这个含义，让人自然地想到，如果我们没有好需求，需求管理，就自然没有意义。另一个含义，就是驱动管理活动的思路与方法，而不一定是管理的实际活动。我们需要知道需求的重要性，以及它的关键因素，才能最有效地管理它。这里的管理，含义在于创造有利条件，才能提高需求质量。
让我再举一个案例：刚才收看了CCTV4的“寻宝”节目。有些观众，拿来评审的文物是假的，有些是非常宝贵的。有些对考古有认识，有些没有。自己在家里收藏古董当然无所谓。但是如果我们要当一位规范的古董鉴赏家，我们是否需要在家里（CMMI第二级）
学习古董的价值与收藏方法（需求管理），才可以放胆投资在真正的古董上面（需求开发）？
所以需求管理，是需求开发的基础。这个跟你的说法是非常一致的。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
12306的已知信息、数据及问题
需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
需求分析（二）—— 涉众、用户体验
核心业务需求及逻辑架构分析
需求分析（三）—— 票仓
票仓设计（一）—— 预生成车票方案的优缺点
票仓设计（二）—— 区间二进制方案的优缺点
票仓设计（三）—— 平衡方案的优缺点
票务并发冲突处理原则设计（基于平衡方案）
缓存逻辑架构设计
灾难备份与恢复
快要太监了 :-(
由于各种个人原因, 铁道部的这个博文系列中止了很久。最近终于连自己都不好意思了。所以还是继续完成它吧，估计1-2周一篇的节奏。
感觉不先划分一下大的系统架构总会让大家感觉有点头晕, 不过没能力对整个12306进行设计，这个货太大了。只是借这个机会谈谈自己对系统结构分析的一些感想
朴素的面向对象分析
面向对象是一个万金油，但是据说真正懂的人不多是吧？
我对面向对象的感觉就是: 他本质上是对现实世界的抽象，其表面现象是不断细分对象的粒度，提升对象的抽象度。最终形成一种用有限数量的独立的对象“积木”构造整个需求不断变化的系统的目标。
而系统级别的分析也大致如此，我们可以借鉴类分析中的很多概念，不断划小系统规模，剥离职责，抽出依赖性。
一般系统结构
这里只是一个简单模型，用以表达我对多数项目的结构分析。
配置数据服务：系统运行所需要的动态配置信息
资产数据服务：所有实际或虚拟的“物”的管理（CRUD），甚至可以包括人。
业务数据服务：该企业实际经营的业务产生的数据。超市的收银记录，企业的销售记录，铁道部的售票记录
报表数据服务：各类统计报表需要的
其中业务系统和业务数据服务应该是最核心的部分。
一般而言，那些配置和资产管理的部分不会造成严重的性能问题。只要在实现CRUD的时候多考虑考虑相关的业务需求，努力做到任何资产的属性变动时，确保相关的业务完整性就好（出租公司管理系统里，一辆出租车今天还在运营，后台系统绝对不应该可以轻松地把它标记成报废车辆，连软删除都是不合理的做法）。
12306之所以能招全国人民围观，我觉得主要还是花的钱和大家的感受之间有落差。而我阴暗的以为这个问题的核心部分就在票务处理的部分。
所以我后续的几篇博文都会围绕票务处理里面的内容展开。
另外，我要大家了解的是，我是要设计一个合理的区间票售票系统核心。而不是实现铁道部的需求。本质上我认为铁道部不会说清楚他自己的需求，而太极公司的需求分析有可以进一步深挖的可能。
12306核心需求及模块分析
整体架构没法子设计，太大了。有兴趣的可以参考
中国铁路客票发售和预订系统5_0版的研究与实现
国铁路客票发售和预订系统5.0版本(TRSv5.0)售票与经由维护操作说明
目前我专注的是用于订票的部分。我感觉这个是最重要的部分。
12306最大的问题，就是如何在订票的时候高效率得并且适当优化得找到需要数量的车票。并且要能彻底保证一张票不会被两个请求同时处理成功。
只要这个问题无法彻底解决，任何分布式处理，最终都会卡在这个问题上。
我会涉及到的模块
12306票务处理功能模块分析
假想完整网络订票流程图
这里实际的用户和系统的交互有4种类型。
1、车次和余额查询
2、订票
3、取消订票
4、确认订票
这里希望广大围观群众都来评估一下这个假设的订票流程及其参数是不是都合理？如果这个流程本身不合理，则我后续的分析都要重写了。不熟悉售票流程的，可以看看我之前的分析文章。
然后我们继续来细化一下
车次和余额查询
输入：起始站，终到站，日期，座位类型集合
输出：车次，对应座位类型可售余额
作用：最终用户根据查询结果选择需要出行的车次，并进一步进入订票操作。但是系统不保证显示为有票的车次在下一步操作中必然有票。
这里其实涉及到两个类型的查询
1、哪些车次符合用户的查询结果，可以通过一个基本固定不变的数据源来提供。而该数据源可以实现分布式缓存以缓解查询压力，甚至可以考虑客户端部分结果缓存。
输入：起始站，终到站，日期
输出 :车次列表，
2、特定车次，特定座位类型的可售票数量。这个数据的来源应该和第一个查询不同。
输入：起始站，终到站，车次，日期
输出：数量
订票(我喜欢称它为锁票)
输入：起始站，终到站，日期，座位类型，需要车票数量，用户ID
输出：实际到的获取车票数量
作用：最终用户通过订票操作，顺利锁定需要数量的车票。系统保证用户在规定的时间段内对这几张车票具有优先订购权利，且其他人不得购买这些车票。
目前我感觉留给用户10-15分钟时间继续后续操作，以进入支付环节（当然，这必须是在系统本身性能良好条件下。否则点个按钮就要等10分钟，那就不对了。）
同时如果超时，则系统会在后续订票操作中忽视该锁定状态。
取消订票
输入：起始站，终到站，日期，座位类型，数量，用户ID
输出：成功标志
作用：用户放弃已经获得的被锁定的售票权利，系统恢复对应的数据为可售。
确认订票（确认支付）
输入：起始站，终到站，日期，座位类型，数量，用户ID，支付相关信息
输出：成功标志/确认失败（刚好锁定超时，且被他人订走）
作用：最终确认售票，系统向第三方支付服务提交确认请求。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters