Wetts's blog

转自：http://www.infoq.com/cn/articles/Java-PERMGEN-Removed

在Java虚拟机（以下简称JVM）中，类包含其对应的元数据，比如类的层级信息，方法数据和方法信息（如字节码，栈和变量大小），运行时常量池，已确定的符号引用和虚方法表。

在过去（当自定义类加载器使用不普遍的时候），类几乎是“静态的”并且很少被卸载和回收，因此类也可以被看成“永久的”。另外由于类作为JVM实现的一部分，它们不由程序来创建，因为它们也被认为是“非堆”的内存。

在JDK8之前的HotSpot虚拟机中，类的这些“永久的”数据存放在一个叫做永久代的区域。永久代一段连续的内存空间，我们在JVM启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小，32位机器默认的永久代的大小为64M，64位的机器则为85M。永久代的垃圾回收和老年代的垃圾回收是绑定的，一旦其中一个区域被占满，这两个区都要进行垃圾回收。但是有一个明显的问题，由于我们可以通过‑XX:MaxPermSize 设置永久代的大小，一旦类的元数据超过了设定的大小，程序就会耗尽内存，并出现内存溢出错误(OOM)。

备注：在JDK7之前的HotSpot虚拟机中，纳入字符串常量池的字符串被存储在永久代中，因此导致了一系列的性能问题和内存溢出错误。想要了解这些永久代移除这些字符串的信息，请访问这里查看。

辞永久代，迎元空间

随着Java8的到来，我们再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域就是我们要提到的元空间。

这项改动是很有必要的，因为对永久代进行调优是很困难的。永久代中的元数据可能会随着每一次Full GC发生而进行移动。并且为永久代设置空间大小也是很难确定的，因为这其中有很多影响因素，比如类的总数，常量池的大小和方法数量等。

同时，HotSpot虚拟机的每种类型的垃圾回收器都需要特殊处理永久代中的元数据。将元数据从永久代剥离出来，不仅实现了对元空间的无缝管理，还可以简化Full GC以及对以后的并发隔离类元数据等方面进行优化。

移除永久代的影响

由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。因此，我们就不会遇到永久代存在时的内存溢出错误，也不会出现泄漏的数据移到交换区这样的事情。最终用户可以为元空间设置一个可用空间最大值，如果不进行设置，JVM会自动根据类的元数据大小动态增加元空间的容量。

注意：永久代的移除并不代表自定义的类加载器泄露问题就解决了。因此，你还必须监控你的内存消耗情况，因为一旦发生泄漏，会占用你的大量本地内存，并且还可能导致交换区交换更加糟糕。

元空间内存管理

元空间的内存管理由元空间虚拟机来完成。先前，对于类的元数据我们需要不同的垃圾回收器进行处理，现在只需要执行元空间虚拟机的C++代码即可完成。在元空间中，类和其元数据的生命周期和其对应的类加载器是相同的。话句话说，只要类加载器存活，其加载的类的元数据也是存活的，因而不会被回收掉。

我们从行文到现在提到的元空间稍微有点不严谨。准确的来说，每一个类加载器的存储区域都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。当一个类加载器被垃圾回收器标记为不再存活，其对应的元空间会被回收。在元空间的回收过程中没有重定位和压缩等操作。但是元空间内的元数据会进行扫描来确定Java引用。

元空间虚拟机负责元空间的分配，其采用的形式为组块分配。组块的大小因类加载器的类型而异。在元空间虚拟机中存在一个全局的空闲组块列表。当一个类加载器需要组块时，它就会从这个全局的组块列表中获取并维持一个自己的组块列表。当一个类加载器不再存活，那么其持有的组块将会被释放，并返回给全局组块列表。类加载器持有的组块又会被分成多个块，每一个块存储一个单元的元信息。组块中的块是线性分配（指针碰撞分配形式）。组块分配自内存映射区域。这些全局的虚拟内存映射区域以链表形式连接，一旦某个虚拟内存映射区域清空，这部分内存就会返回给操作系统。

上图展示的是虚拟内存映射区域如何进行元组块的分配。类加载器1和3表明使用了反射或者为匿名类加载器，他们使用了特定大小组块。 而类加载器2和4根据其内部条目的数量使用小型或者中型的组块。

元空间调优与工具

正如上面提到的，元空间虚拟机控制元空间的增长。但是有些时候我们想限制其增长，比如通过显式在命令行中设置-XX:MaxMetaspaceSize。默认情况下，-XX:MaxMetaspaceSize的值没有限制，因此元空间甚至可以延伸到交换区，但是这时候当我们进行本地内存分配时将会失败。

对于一个64位的服务器端JVM来说，其默认的–XX:MetaspaceSize值为21MB。这就是初始的高水位线。一旦触及到这个水位线，Full GC将会被触发并卸载没有用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，这个高水位线则上升。如果释放空间过多，则高水位线下降。如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志我们可以观察到Full GC多次调用。为了避免频繁的GC，建议将–XX:MetaspaceSize设置为一个相对较高的值。

经过多次GC之后，元空间虚拟机自动调节高水位线，以此来推迟下一次垃圾回收到来。

有这样两个选项 ‑XX:MinMetaspaceFreeRatio和‑XX:MaxMetaspaceFreeRatio，他们类似于GC的FreeRatio选项，用来设置元空间空闲比例的最大值和最小值。我们可以通过命令行对这两个选项设置对应的值。

下面是一些改进的工具，用来获取更多关于元空间的信息。

• jmap -clstats PID 打印类加载器数据。（-clstats是-permstat的替代方案，在JDK8之前，-permstat用来打印类加载器的数据）。下面的例子输出就是DaCapo’s Avrora benchmark程序的类加载器数据

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  $ jmap -clstats Attaching to process ID 6476, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.5-b02 finding class loader instances ..done. computing per loader stat ..done. please wait.. computing liveness.liveness analysis may be inaccurate ... class_loader classes bytes parent_loader alive? type 655 1222734 null live 0x000000074004a6c0 0 0 0x000000074004a708 dead java/util/ResourceBundle$RBClassLoader@0x00000007c0053e20 0x000000074004a760 0 0 null dead sun/misc/Launcher$ExtClassLoader@0x00000007c002d248 0x00000007401189c8 1 1471 0x00000007400752f8 dead sun/reflect/DelegatingClassLoader@0x00000007c0009870 0x000000074004a708 116 316053 0x000000074004a760 dead sun/misc/Launcher$AppClassLoader@0x00000007c0038190 0x00000007400752f8 538 773854 0x000000074004a708 dead org/dacapo/harness/DacapoClassLoader@0x00000007c00638b0 total = 6 1310 2314112 N/A alive=1, dead=5 N/A

• jstat -gc LVMID 用来打印元空间的信息，具体内容如下
  

• jcmd PID GC.class_stats 一个新的诊断命令，用来连接到运行的JVM并输出详尽的类元数据的柱状图。

  注意：在JDK 6 build 13下，需要加上‑XX:+UnlockDiagnosticVMOptions 才能正确使用jcmd这个命令。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  $ jcmd help GC.class_stats 9522: GC.class_stats Provide statistics about Java class meta data. Requires -XX:+UnlockDiagnosticVMOptions. Impact: High: Depends on Java heap size and content. Syntax : GC.class_stats [options] [] Arguments: columns : [optional] Comma-separated list of all the columns to show. If not specified, the following columns are shown: InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes,MethodAll,ROAll,RWAll,Total (STRING, no default value) Options: (options must be specified using the or = syntax) -all : [optional] Show all columns (BOOLEAN, false) -csv : [optional] Print in CSV (comma-separated values) format for spreadsheets (BOOLEAN, false) -help : [optional] Show meaning of all the columns (BOOLEAN, false)

  提示：如果想了解字段的更多信息，请访问这里

使用jcmd的示例输出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

$ jcmd  GC.class_stats

7140:
Index Super InstBytes KlassBytes annotations   CpAll MethodCount Bytecodes MethodAll   ROAll   RWAll   Total ClassName
    1    -1    426416        480           0       0           0         0         0      24     576     600 [C
    2    -1    290136        480           0       0           0         0         0      40     576     616 [Lavrora.arch.legacy.LegacyInstr;
    3    -1    269840        480           0       0           0         0         0      24     576     600 [B
    4    43    137856        648           0   19248         129      4886     25288   16368   30568   46936 java.lang.Class
    5    43    136968        624           0    8760          94      4570     33616   12072   32000   44072 java.lang.String
    6    43     75872        560           0    1296           7       149      1400     880    2680    3560 java.util.HashMap$Node
    7   836     57408        608           0     720           3        69      1480     528    2488    3016 avrora.sim.util.MulticastFSMProbe
    8    43     55488        504           0     680           1        31       440     280    1536    1816 avrora.sim.FiniteStateMachine$State
    9    -1     53712        480           0       0           0         0         0      24     576     600 [Ljava.lang.Object;
   10    -1     49424        480           0       0           0         0         0      24     576     600 [I
   11    -1     49248        480           0       0           0         0         0      24     576     600 [Lavrora.sim.platform.ExternalFlash$Page;
   12    -1     24400        480           0       0           0         0         0      32     576     608 [Ljava.util.HashMap$Node;
   13   394     21408        520           0     600           3        33      1216     432    2080    2512 avrora.sim.AtmelInterpreter$IORegBehavior
   14   727     19800        672           0     968           4        71      1240     664    2472    3136 avrora.arch.legacy.LegacyInstr$MOVW
…
…
1299  1300         0        608           0     256           1         5       152     104    1024    1128 sun.util.resources.LocaleNamesBundle
 1300  1098         0        608           0    1744          10       290      1808    1176    3208    4384 sun.util.resources.OpenListResourceBundle
 1301  1098         0        616           0    2184          12       395      2200    1480    3800    5280 sun.util.resources.ParallelListResourceBundle
              2244312     794288        2024 2260976       12801    561882   3135144 1906688 4684704 6591392 Total
                34.0%      12.1%        0.0%   34.3%           -      8.5%     47.6%   28.9%   71.1%  100.0%
Index Super InstBytes KlassBytes annotations   CpAll MethodCount Bytecodes MethodAll   ROAll   RWAll   Total ClassName

存在的问题

前面已经提到，元空间虚拟机采用了组块分配的形式，同时区块的大小由类加载器类型决定。类信息并不是固定大小，因此有可能分配的空闲区块和类需要的区块大小不同，这种情况下可能导致碎片存在。元空间虚拟机目前并不支持压缩操作，所以碎片化是目前最大的问题。

使用异常而非返回码

如果使用返回码，调用者必须在调用之后即刻检查错误。

遇到错误时，最好抛出一个异常。调用代码很整洁，其逻辑不会被错误处理搞乱。

使用不可控异常

Java的第一个版本中引入可控异常时，看似一个极好的点子。每个方法的签名都列出它可能传递给调用者的异常，这些异常就是方法类型的一部分。

可控异常的代价就是违反了开放/闭合原则。如果你在方法中抛出可控异常，而catch语句在三个层级之上，你就得在catch语句和抛出异常处之间的每个方法签名中声明该异常。这意味着对软件中较低层级的修改，都将波及较高层级的签名。

如果你在编写一套关键代码库，则可控异常有时也会有用：你必须捕获异常。但对于一般的应用开发，其依赖成本要高于收益。

依调用者需要定义异常类

来看一个不太好的异常分类例子。下面的try-catch-finally语句是对某个第三方代码库的调用。它覆盖了该调用可能抛出的所有异常：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

ACMEPort port = new ACMEPort(12);

try {
  port.open();
} catch (DeviceResponseException e) {
  reportPortError(e);
  logger.log("Device response exception", e);
} catch (ATM1212UnlockedException e) {
  reportPortError(e);
  logger.log("Unlock exception", e);
} catch (GMXError e) {
  reportPortError(e);
  logger.log("Device response exception");
} finally {
  ...
}

语句包含了一大堆重复代码。在大多数异常处理中，不管真实原因如何，我们总是做相对标准的处理。

在本例中，既然知道我们所做的事不外如此，就可以通过打包调用API、确保它返回通用异常类型，从而简化代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

LocalPort port = new LocalPort(12);

try {
  port.open();
} catch (PortDeviceFailure e) {
  reportError(e);
  logger.log(e.getMessage(), e);
} finally {
  ...
}

// LocalPort类就是简单的打包类，捕获并翻译由ACMEPort类抛出的异常：
public class LocalPort {
  private ACMEPort innerPort;

  public LocalPort(int portNumber) {
    innerPort = new ACMEPort(portNumber);
  }

  public void open() {
    try {
      innerPort.open();
    } catch (DeviceResponseException e) {
      throw new PortDeviceFailure(e);
    } catch (ATM1212UnlockedException e) {
      throw new PortDeviceFailure(e);
    } catch (GMXError e) {
      throw new PortDeviceFailure(e);
    }
  }
}

实际上，将第三方API打包是个良好的实践手段。当你打包一个第三方API，你就降低了对它的依赖：未来你可以不太痛苦地改用其他代码库。在你测试自己的代码时，打包也有助于模拟第三方调用。

打包的好处还在于你不必绑死在某个特定厂商的API设计上。你可以定义自己感觉舒服的API。在上例中，我们为port设备的错误定义了一个异常类型，然后发现这样能写出更整洁的代码。

对于代码的某个特定区域，单一异常类通常可行。伴随异常发送出来的信息能够区分不同错误。如果你想要捕获某个异常，并且放过其他异常，就使用不同的异常类。

别返回null值

返回null值，基本上是在给自己增加工作量，也是在给调用者添乱。只要有一处没检查null值，应用程序就会失控。

别传递null值

除非API要求你向它传递null值，否则就要尽可能避免传递null值。

整洁代码是可读的，但也要强固。可读与强固并不冲突，如果将错误处理隔离开看待，独立于主要逻辑之外，就能写出强固而整洁的代码。做到这一步，我们就能单独处理它，也极大地提升了代码的可维护性。

nload

让用户可以分开来监控入站流量和出站流量

iftop

可测量通过每一个套接字连接传输的数据；它采用的工作方式有别于nload。iftop使用pcap库来捕获进出网络适配器的数据包，然后汇总数据包大小和数量，搞清楚总的带宽使用情况。

• 对象把数据隐藏于抽象之后，暴露操作数据的函数。
• 数据结构暴露其数据，没有提供有意义的函数。

这两种定义的本质，它们是对立的。

对象与数据结构之间的二分原理：

过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。

反过来说：

过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。

转自：http://www.cnblogs.com/antineutrino/p/4213268.html

Java字符串的截取操作可以通过substring来完成。有意思的是，这个方法从jdk1.0开始，一直到1.6都没有变化，但到了1.7实现方式却发生了改变。你可能会认为之所以要对一个成熟且稳定的方法做修改，一定是因为新的实现更好、效率更高吧？然而正好相反，修改后的substring的效率变低了，并且占用了更多的内存，无论是从时间上还是空间上都比不上原有的实现。下面我们来做一个比较，看看到底哪一个更好，以及为什么新版Java中要对其进行修改。

原有实现

我们首先来看看原来的substring方法。前面是对参数进行检查，重点是最后一句：

1
2

return ((beginIndex == 0) && (endIndex == count)) ? this :
  new String(offset + beginIndex, endIndex - beginIndex, value);

这里通过调用下面这个构造方法来创建一个新的字符串：

1
2
3
4
5
6

// Package private constructor which shares value array for speed.
String(int offset, int count, char value[]) {
  this.value = value;
  this.offset = offset;
  this.count = count;
}

我们知道，Java的字符串实际上是用一个字符数组来实现的，这个构造方法通过复用字符数组value，省去了数组拷贝的开销，仅通过3个赋值语句就创建了一个新的字符串对象。从注释也可以看出这个构造方法的意图就是为了提升性能。

新的实现

我们再来看看1.7中新的substring实现。前面一堆还是参数检查，直接看最后一句：

1
2

return ((beginIndex == 0) && (endIndex == value.length)) ? this
  : new String(value, beginIndex, subLen);

与原来的差不多，但是请注意，这次调用的是另一个构造方法：

1

public String(char[], int, int)

这个公有的构造方法和前面那个很相似（那个是包私有的），从方法签名上看区别仅仅是参数顺序不同。不过这只是表面现象，它们的内部实现却是完全不同的，这个公有的构造方法不会复用char[]数组，而是将其拷贝到一个新数组，从而创建一个新字符串。

1

this.value = Arrays.copyOfRange(value, offset, offset+count);

对公有的构造方法来说，必须采用这种方式，如果仍然采用复用数组的方法，就会发生安全性问题，别人就可以对字符串中的字符进行任意的修改。后面会对此进行分析。

复用字符数组有没有安全隐患

Java的字符串是不可变的，原因是作为字符串底层实现的字符数组是私有的，从外面无法访问。另一方面，String类的每一个可以创建新字符串的公有方法（构造方法、valueOf等），如果其接受一个字符数组作为参数，就会对该数组执行拷贝操作，这就进一步保证了只有String对象才会持有它的字符数组，因此断绝了从外部修改数组的一切可能。

如果不这么做就会带来问题，字符串的不可变性也就不复存在了。比如下面这个假想的程序：

1
2
3
4

char[] arr = new char[] {'h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd'};
String s = new String(0, arr.length, arr); // "hello world"
arr[0] = 'a'; // replace the first character with 'a'
System.out.println(s); // aello world

如果构造方法没有对arr进行拷贝，那么其他人就可以在字符串外部修改该数组，由于它们引用的是同一个数组，因此对arr的修改就相当于修改了字符串。（可以通过反射来真正地实现这个假想的程序）

还有一些方法，比如原来的substring方法，它们没有进行数组拷贝，而是直接复用另一个字符串的内部数组。这样做会导致安全问题吗？答案是不会，因为所有这些方法所执行的操作都是私有操作或包私有操作，属于内部实现，因此只要不对外暴露这些操作的接口就仍然是安全的。

例如对substring来说，由于无论是原字符串还是新字符串，其value数组本身都是String对象的私有属性，从外部是无法访问的，因此对两个字符串来说都很安全。

为何要修改substring

原来的substring在安全上没有问题，而且性能很好，又能共享内部数组节约内存。这么看来，好像并没有什么缺点。那为什么要放弃性能更好的实现方式，而采用性能差很多的数组拷贝的方式呢？难道是Oracle的工程师脑抽才会对substring做出这样的修改吗？

当然不是，原来的方法比新的好只是表面现象，因为虽然性能好，但是有一个严重的问题，那就是有可能会导致内存泄漏。看一个例子，假设一个方法从某个地方（文件、数据库或网络）取得了一个很长的字符串，然后对其进行解析并提取其中的一小段内容，这种情况经常发生在网页抓取或进行日志分析的时候。下面是示例代码。

1
2
3

String aLongString = ...; // a very long string
String aPart = data.substring(20, 40);
return aPart;

在这里aLongString只是临时的，真正有用的是aPart，其长度只有20个字符，但是它的内部数组却是从aLongString那里共享的，因此虽然aLongString本身可以被回收，但它的内部数组却不能（如下图）。这就导致了内存泄漏。如果一个程序中这种情况经常发生有可能会导致严重的后果，如内存溢出，或性能下降。

新的实现虽然损失了性能，而且浪费了一些存储空间，但却保证了字符串的内部数组可以和字符串对象一起被回收，从而防止发生内存泄漏，因此新的substring比原来的更健壮。

实际上前面所说的那个包私有的构造方法在1.7中已经被标记为Deprecated，并且实现也修改为直接调用“public String(char[], int, int)”。到了1.8这个构造方法就被删除了。取而代之的是从1.7开始，增加了另一个共享版的构造方法，这个方法也是包私有的：

1
2
3
4

String(char[] value, boolean share) {
  // assert share : "unshared not supported";
  this.value = value;
}

第二个参数目前没有用到，始终为true，仅仅是为了和另一个公有构造方法“String(char[])”相区别才增加了这么一个参数。这个构造方法用来创建一个和原字符串一模一样的字符串，而不是像以前一样可以创建原字符串的一个子串。在这种情况下，共享数组不会导致内存泄漏问题，只是其用处大打折扣，因为只有很少的情况需要创建一个和原字符串一模一样的字符串，多数情况只需使用原字符串即可。这就像构造方法“String(String)”一样，应该很少有人会使用它来创建字符串吧。

总结

原来的substring性能好，但在一些情况下却可能导致严重的内存泄漏。新的substring没有内存泄漏的隐患，因此健壮性更好，但却是通过牺牲性能换来的。

两种实现孰优孰劣还真不好说，因为在大多数情况下都不会遇到所谓的严重内存泄漏的情况，因此大部分时候新的substring都不如原来的好。但对一个运行库来说，健壮性可能更重要一些，毕竟它需要适用于任何可能遇到的情况。

垂直格式

• 垂直方向上的间隔

  在封包声明、导入声明和每个函数之间，都有空白行隔开。

• 垂直方向上的靠近

  在方法中，紧密相关的代码应该互相靠近。

• 垂直距离

  实体变量应该在类的顶部声明。

  若某个函数调用了另外一个，就应该把它们放到一起，而且调用者应该尽可能放在被调用者上面。

  概念相关的代码应该放到一起。相关性越强，彼此之间的距离就该越短。

• 垂直顺序

  调用者应该尽可能放在被调用者上面。

横向格式

应该尽力保持代码行短小。死守80个字符的上限有点僵化，而且我也并不反对代码行长度达到100个字符或120个字符。

注释不能美化糟糕的代码

带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样得多。

用代码来阐述

1

if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

or

1

if (employee.isEligibleForFullBenefites())

只要想上那么几秒钟，就能用代码解释你大部分的意图。很多时候，简单到只需要创建一个描述与注释所言同一事物的函数即可。

函数的规则：

• 短小

  • 代码块和缩进

    if语句、else语句、while语句等，其中的代码块应该只有一行。该行大抵应该是一个函数调用语句。这样不但能保持函数短小，而且，因为块内调用的函数拥有较具说明性的名称，从而增加了文档上的价值。

    这也意味着函数不应该大到足以容纳嵌套结构。所以，函数的缩进层级不该多于一层或两层。当然，这样的函数易于阅读和理解。

• 只做一件事

• 每个函数一个抽象级别

• 使用描述性的命名

• 函数参数尽量少

  最理想的参数数量是零（零参数函数），其次是一（单参数函数），再次是二（双参数函数），应尽量避免三（三参数函数）。有足够特殊的理由才能用三个以上参数（多参数函数）——————所以无论如何也不要这么做。

  从测试的角度看，参数过多测试覆盖所有可能值的组合让人生畏。

  • 标识参数

    向函数传入布尔值简直就是骇人听闻的做法。这样做标识着导致该函数不止做一件事。

  如果函数看来需要两个、三个或三个以上参数，就说明其中一些参数应该封装为类了。

• 分隔指令与询问

  public boolean set(String attribute, String value); 该函数设置某个指定属性，如果成功就返回true，如果不存在那个属性则返回false。

  这就会导致以下的语句：if (set("username", "unclebob")) ...。

  作者本意，set是个动词，但在if语句的上下文中，感觉它像是个形容词。该语句读取来像是说“如果username属性值之前已被设置为unclebob”，而不是“设置username属性值为unclebob，看看是否可行，然后……”。要解决这个问题，可以将set函数重命名为setAndCheckIfExists，但这对提高if语句的可读性帮助不大。真正的解决方案是把指令与询问分割开来，防止混淆的发生：

  1 2 3 4

  if (attributeExists("username")) { setAttribute("username","unclebob"); ... }

• 使用异常代替返回错误码

• 避免重复的代码

类名

类名和对象名应该是名词或名词短语，如Customer、WikiPage、Account和AddressParser。避免使用Manager、Processor、Data或Info这样的类名。类名不应当是动词。

方法名

方法名应当是动词或动词短语，如postPayment、deletePage或save。属性访问器、修改器和断言应该根据其值命名，并依Javabean标准记上get、set和is前缀。

• 常量避免硬编码
• 使用有意义的名字

转自：http://stackoverflow.com/questions/34054780/how-can-mongodb-datasize-be-larger-than-storagesize

The storageSize metric is equal to the size (in bytes) of all the data extents in the database. Without compression, this number is larger than dataSize because it includes yet-unused space (in data extents) and space vacated by deleted or moved documents within extents. However, as you are using the WiredTiger storage engine, data is compressed on the disk and is therefore smaller than the dataSize.