This article will give you the general advices on memory consumption optimization in Java.

Memory usage optimization is the most important type of optimization in Java. Current systems are limited by memory access times rather than by CPU frequency (otherwise, why CPU producers are implementing all these L1s, L2s and L3s?). It means that by reducing your application memory footprint you will most likely improve your program data processing speed by making your CPU to wait for smaller amount of data. Now let’s get back to Java.

General Java memory layout information

First of all, we have to revise the memory layout of Java objects: any Java Object occupies at least 16 bytes, 12 out of which are occupied by a Java object header. Besides that, all Java objects are aligned by 8 bytes boundary. It means that, for example, an object containing 2 fields: int and byte will occupy not 17 (12 + 4 + 1), but 24 bytes (17 aligned by 8 bytes).

Each Object reference occupies 4 bytes if the Java heap is under 32G andXX:+UseCompressedOops is turned on (it is turned on by default in the recent Oracle JVM versions). Otherwise, Object references occupy 8 bytes.

All primitive data types occupy their exact byte size:

In essence, this information is sufficient for Java memory optimization. But it will be more convenient if you will be aware of arrays / String / numeric wrappers memory consumption.

Most common Java types memory consumption

Arrays consume 12 bytes plus their length multiplied by their element size (and, of course, rounded by 8 bytes alignment).

From Java 7 build 06 String contains 3 fields – a char[] with the string data plus 2 int fields with 2 hash codes calculated by the different algorithms. It means that a String itself needs 12 (header) + 4 (char[] reference) + 4 * 2 (int) = 24 bytes (as you can see, it exactly fits in 8 byte alignment). Besides that, a char[] with the String data occupies 12 + length * 2 bytes (plus alignment). It means that a String occupies 36 + length*2 bytes aligned by 8 bytes (which is, by the way, 8 byte less than a String memory consumption prior to Java 7 build 06).

Numeric wrappers occupy 12 bytes plus size of the underlying type.Byte/Short/Character/Integer/Long are cached by JDK, so the actual memory consumption may be smaller for values in the range [-128; 127]. Anyway, these type may be the source of serious memory overhead in the collection-based applications:

General Java memory optimization tips

With all this knowledge at hand it is not difficult to give the general Java memory optimization tips:

• Prefer primitive types to their Object wrappers. The main cause of wrapper types usage are JDK collections, so consider using one of primitive type collection frameworks likeTrove.
• Try to minimize number of Objects you have. For example, prefer array-based structures like ArrayList/ArrayDeque to pointer based structures like LinkedList.

Java memory optimization example

Here is an example. Suppose you have to create a map from int to 20 character long strings. The size of this map is equal to one million and all mappings are static and predefined (saved in some dictionary, for example).

The first approach is to use a Map<Integer, String> from the standard JDK. Let’s roughly estimate the memory consumption of this structure. Each Integer occupies 16 bytes plus 4 bytes for an Integer reference from a map. Each 20 character long String occupies 36 + 20*2 = 76 bytes (see String description above), which are aligned to 80 bytes. Plus 4 bytes for a reference. The total memory consumption will be roughly (16 + 4 + 80 + 4) * 1M = 104M.

The better approach will be replacing String with a byte[] in UTF-8 encoding as described inString packing part 1: converting characters to bytes article. Our map will be Map<Integer, byte[]>. Assume that all string characters belong to ASCII set (0-127), which is true in most of English-speaking countries. A byte[20] occupies 12 (header) + 20*1 = 32 bytes, which conveniently fit into 8 bytes alignment. The whole map will now occupy (16 + 4 + 32 + 4) * 1M = 56M, which is 2 times less than the previous example.

Now let’s use Trove TIntObjectMap<byte[]>. It stores keys as normal int[] compared to wrapper types in JDK collections. Each key will now occupy exactly 4 bytes. The total memory consumption will go down to (4 + 32 + 4) * 1M = 40M.

The final structure will be more complicated. All String values will be stored in the singlebyte[] one after another with (byte)0 as a separator (we still assume we have a text-based ASCII strings). The whole byte[] will occupy (20 + 1) * 1M = 21M. Our map will store an offset of the string in the large byte[] instead of the string itself. We will use Trove TIntIntMap for this purpose. It will consume (4 + 4) * 1M = 8M. The total memory consumption in this example will be 8M + 21M = 29M. By the way, this is the first example relying on the immutability of this dataset.

Can we achieve the better result? Yes, we can, but at a cost of CPU consumption. The obvious ‘optimization’ is to sort the whole dataset by keys before storing values into a large byte[]. Now we may store the keys in the int[] and use a binary search to look for a key. If a key is found, its index multiplied by 21 (remember, all strings have the same length) will give us the offset of a value in the byte[]. This structure occupies ‘only’ 21M + 4M (for int[]) = 25Mat a price of O(log N) lookups compared to O(1) lookups in case of a hash map.

Is this the best we can do? No! We have forgotten that all values are 20 characters long, so we don’t actually need the separators in the byte[]. It means that we can store our ‘map’ using 24M memory if we agree on O( log N ) lookups. No overhead at all compared to theoretical data size and nearly 4.5 times less than required by the original solution (Map<Integer, String> )! Who told you that Java programs are memory hungry?

In second part of this article we will look at a few commonly used Java types memory consumption.

Summary

• Prefer primitive types to their Object wrappers. The main cause of wrapper types usage are JDK collections, so consider using one of primitive type collection frameworks likeTrove.
• Try to minimize number of Objects you have. For example, prefer array-based structures like ArrayList/ArrayDeque to pointer based structures like LinkedList.

Recommended reading

If you want to find out more about the clever data compression algorithms, it worth to read“Programming Pearls” (second edition) by Jon Bentley. This is a wonderful collection of rather unexpected algorithms. For example, in column 13.8 author has described how Doug McIlroy managed to fit a 75,000 word spellchecker just in 64 kilobytes of RAM. That spellchecker kept all required information in that tiny amount of memory and did not use disks! It may also be noticed that “Programming Pearls” is one of recommended preparation books for Google SRE interviews.

节选文章：

• An overview of memory saving techniques in Java
• Memory consumption of popular Java data types – part 1
• Memory consumption of java data types 2
• Java collections overview
• A few more memory saving techniques in Java

Java开发内存优化导读，首发于润物无声。

It is quite simple to use, as explained by the author:

        
MemoryMeter meter = new MemoryMeter();
meter.measure(object);
meter.measureDeep(object);
meter.countChildren(object);

        
< dependencies > 
      < dependency > 
          < groupid >junit</ groupid > 
          < artifactid >junit</ artifactid > 
          < version >4.11</ version > 
          < scope >test</ scope > 
      </ dependency > 

      <!-- jamm java agent --> 
      < dependency > 
          < groupid >com.github.stephenc</ groupid > 
          < artifactid >jamm</ artifactid > 
          < version >0.2.5</ version > 
          < scope >test</ scope > 
      </ dependency > 

 </ dependencies > 

 < build > 
      < plugins > 

          <!-- copies java agent dependency into the target directory --> 
          < plugin > 
              < groupid >org.apache.maven.plugins</ groupid > 
              < artifactid >maven-dependency-plugin</ artifactid > 
              < version >2.8</ version > 
              < executions > 
                  < execution > 
                      < id >copy-dependencies</ id > 
                      < phase >generate-test-resources</ phase > 
                      < goals > 
                          < goal >copy</ goal > 
                      </ goals > 
                      < configuration > 
                          < artifactitems > 
                              < artifactitem > 
                                  < groupid >com.github.stephenc</ groupid > 
                                  < artifactid >jamm</ artifactid > 
                                  < version >0.2.5</ version > 
                                  < type >jar</ type > 
                                  < outputdirectory >${project.build.directory}</ outputdirectory > 
                                  < destfilename >jamm.jar</ destfilename > 
                              </ artifactitem > 
                          </ artifactitems > 
                      </ configuration > 
                  </ execution > 
              </ executions > 
          </ plugin > 

          <!-- executes test with java agent options of the JVM --> 
          < plugin > 
              < groupid >org.apache.maven.plugins</ groupid > 
              < artifactid >maven-surefire-plugin</ artifactid > 
              < version >2.14</ version > 
              < configuration > 
                  < argline >-javaagent:${project.build.directory}/jamm.jar</ argline > 
              </ configuration > 
          </ plugin > 

      </ plugins > 
 </ build >

Next, write the following JUnit that explores the JAMM features:

 package org.javabenchmark.memory; 

 import java.util.ArrayList; 
 import java.util.List; 
 import org.github.jamm.MemoryMeter; 
 import org.junit.Test; 

 public class MemoryMeterTest { 

      private MemoryMeter meter = new MemoryMeter(); 

      @Test 
      public void shouldMeasureMemoryUsage() { 

          String st1 = "This is the string #1" ; 
          measure(st1); 

          String st2 = "This is the string #2 and it has more chars." ; 
          measure(st2); 

          List aList = new ArrayList( 0 ); 
          measure(aList); 

          aList.add(st1); 
          measure(aList); 

          aList.add(st2); 
          measure(aList); 
      } 

      private void measure(Object anObject) { 
          System.out.println( "-----------------------------------" ); 
          System.out.printf( "size: %d bytes\n" , meter.measure(anObject)); 
          System.out.printf( "retained size: %d bytes\n" , meter.measureDeep(anObject)); 
          System.out.printf( "inner object count: %d\n" , meter.countChildren(anObject)); 
      } 
 }

Running the test produces the following output on my computer:

 ----------------------------------- 
 size: 24 bytes 
 retained size: 88 bytes 
 inner object count: 2 
 ----------------------------------- 
 size: 24 bytes 
 retained size: 128 bytes 
 inner object count: 2 
 ----------------------------------- 
 size: 24 bytes 
 retained size: 40 bytes 
 inner object count: 2 
 ----------------------------------- 
 size: 24 bytes 
 retained size: 136 bytes 
 inner object count: 4 
 ----------------------------------- 
 size: 24 bytes 
 retained size: 264 bytes 
 inner object count: 6

To conclude, you can see how it is easy to monitor the memory usage of your objects. It is very handy when dealing with huge collections, or when using caches such as the ones provided by Guava or EHCache. That way you can setup trigger that alert when memory consumption is excessive.

注意：

如果在调试的过程中，发现内存不足的情况，请调整JVM的启动参数。

JVM options: -Xms256m -Xmx256m.

文章选自：compute-java-object-memory-footprint-at.html

Java开发内存占用监测，首发于润物无声。

Java developers mix object-oriented thinking with imperative thinking, depending on their levels of:

• Skill (anyone can code imperatively)
• Dogma (some use the “Pattern-Pattern”, i.e. the pattern of applying patterns everywhere and giving them names)
• Mood (true OO is more clumsy to write than imperative code. At first)

But when Java developers write SQL, everything changes. SQL is a declarative language that has nothing to do with either object-oriented or imperative thinking. It is very easy to express a query in SQL. It is not so easy to express it optimally or correctly. Not only do developers need to re-think their programming paradigm, they also need to think in terms of set theory.

Here are common mistakes that a Java developer makes when writing SQL (in no particular order):

1. Forgetting about NULL

Misunderstanding NULL is probably the biggest mistake a Java developer can make when writing SQL. This is also (but not exclusively) due to the fact that NULL is also called UNKNOWN. If it were only called UNKNOWN, it would be easier to understand. Another reason is that JDBC maps SQL NULL to Java null when fetching data or when binding variables. This may lead to thinking that NULL = NULL (SQL) would behave the same way as null == null (Java)

One of the crazier examples of misunderstanding NULL is when NULL predicates are used with row value expressions.

Another, subtle problem appears when misunderstanding the meaning ofNULL in NOT IN anti-joins.

The Cure:

Train yourself. There’s nothing but explicitly thinking about NULL, every time you write SQL:

• Is this predicate correct with respect to NULL?
• Does NULL affect the result of this function?

2. Processing data in Java memory

Few Java developers know SQL very well. The occasional JOIN, the odd UNION, fine. But window functions? Grouping sets? A lot of Java developers load SQL data into memory, transform the data into some appropriate collection type, execute nasty maths on that collection with verbose loop structures (at least, before Java 8′s Collection improvements).

But some SQL databases support advanced (and SQL standard!) OLAP features that tend to perform a lot better and are much easier to write. A (non-standard) example is Oracle’s awesome MODEL clause. Just let the database do the processing and fetch only the results into Java memory. Because after all some very smart guys have optimised these expensive products. So in fact, by moving OLAP to the database, you gain two things:

• Simplicity. It’s probably easier to write correctly in SQL than in Java
• Performance. The database will probably be faster than your algorithm. And more importantly, you don’t have to transmit millions of records over the wire.

The Cure:

Every time you implement a data-centric algorithm in Java, ask yourself: Is there a way to let the database perform that work for me?

3. Using UNION instead of UNION ALL

It’s a shame that UNION ALL needs an extra keyword compared to UNION. It would be much better if the SQL standard had been defined to support:

• UNION (allowing duplicates)
• UNION DISTINCT (removing duplicates)

Not only is the removal of duplicates rarely needed (or sometimes even wrong), it is also quite slow for large result sets with many columns, as the two subselects need to be ordered, and each tuple needs to be compared with its subsequent tuple.

Note that even if the SQL standard specifies INTERSECT ALL and EXCEPT ALL, hardly any database implements these less useful set operations.

The Cure:

Every time you write a UNION, think if you actually wanted to write UNION ALL.

4. Using JDBC Paging to page large results

Most databases support some way of paging ordered results through LIMIT .. OFFSET, TOP .. START AT, OFFSET .. FETCH clauses. In the absence of support for these clauses, there is still the possibility for ROWNUM (Oracle)or ROW_NUMBER() OVER() filtering (DB2, SQL Server 2008 and less), which is much faster than paging in memory. This is specifically true for large offsets!

The Cure:

Just use those clauses, or a tool (such as jOOQ) that can simulate those clauses for you.

5. Joining data in Java memory

From early days of SQL, some developers still have an uneasy feeling when expressing JOINs in their SQL. There is an inherent fear of JOIN being slow. This can be true if a cost-based optimiser chooses to perform a nested loop, possibly loading complete tables into database memory, before creating a joined table source. But that happens rarely. With appropriate predicates, constraints and indexes, MERGE JOIN and HASH JOIN operations are extremely fast. It’s all about the correct metadata (I cannot cite Tom Kyte often enough for this). Nonetheless, there are probably still quite a few Java developers who will load two tables from separate queries into maps and join them in Java memory in one way or another.

The Cure:

If you’re selecting from various tables in various steps, think again to see if you cannot express your query in a single statement.

6. Using DISTINCT or UNION to remove duplicates from an accidental cartesian product

With heavy joining, one can loose track of all the relations that are playing a role in a SQL statement. Specifically, if multi-column foreign key relationships are involved, it is possible to forget to add the relevant predicates in JOIN .. ON clauses. This might result in duplicate records, but maybe only in exceptional cases. Some developers may then choose to use DISTINCT to remove those duplicates again. This is wrong in three ways:

• It (may) solve the symptoms but not the problem. It may as well not solve the symptoms in edge-cases.
• It is slow for large result sets with many columns. DISTINCT performs an ORDER BY operation to remove duplicates.
• It is slow for large cartesian products, which will still load lots of data into memory

The Cure:

As a rule of thumb, when you get unwanted duplicates, always review your JOIN predicates. There’s probably a subtle cartesian product in there somewhere.

7. Not using the MERGE statement

This isn’t really a mistake, but probably some lack of knowledge or some fear towards the powerful MERGE statement. Some databases know other forms of UPSERT statements, e.g. MySQL’s ON DUPLICATE KEY UPDATE clause. But MERGE is really so powerful, most importantly in databases that heavily extend the SQL standard, such as SQL Server.

The Cure:

If you’re UPSERTING by chaining INSERT and UPDATE or by chaining SELECT .. FOR UPDATE and then INSERT or UPDATE, think again. Apart from risking race conditions, you might be able to express a simpler MERGE statement.

8. Using aggregate functions instead of window functions

Before the introduction of window functions, the only means to aggregate data in SQL was by using a GROUP BY clause along with aggregate functions in the projection. This works well in many cases, and if aggregation data needed to be enriched with regular data, the grouped query can be pushed down into a joined subquery.

But SQL:2003 defined window functions, which are implemented by many popular database vendors. Window functions can aggregate data on result sets that are not grouped. In fact, each window function supports its own, independent PARTITION BY clause, which is an awesome tool for reporting.

Using window functions will:

• Lead to more readable SQL (less dedicated GROUP BY clauses in subqueries)
• Improve performance, as a RDBMS is likely to optimise window functions more easily

The Cure:

When you write a GROUP BY clause in a subquery, think again if this cannot be done with a window function.

9. Using in-memory sorting for sort indirections

The SQL ORDER BY clause supports many types of expressions, including CASE statements, which can be very useful for sort indirections. You should probably never sort data in Java memory because you think that

• SQL sorting is too slow
• SQL sorting cannot do it

The Cure:

If you sort any SQL data in memory, think again if you cannot push sorting into your database. This goes along well with pushing paging into the database.

10. Inserting lots of records one by one

JDBC knows batching, and you should use it. Do not INSERT thousands of records one by one, re-creating a new PreparedStatement every time. If all of your records go to the same table, create a batch INSERT statement with a single SQL statement and multiple bind value sets. Depending on your database and database configuration, you may need to commit after a certain amount of inserted records, in order to keep the UNDO log slim.

The Cure:

Always batch-insert large sets of data.

Some interesting books

Some very interesting books on similar topics are

• SQL Antipatterns by Bill Karwin
• SQL Performance Explained by Markus Winand

本文选自：10-common-mistakes-java-developers-make-when-writing-sql

Java语言开发之SQL语句改善，首发于润物无声。

客户端采用Java语言编写，服务器端采用PHP语言编写，数据库采用Mysql存储，客户端和服务器之间的交互采用Json，在传递英文数据的时候没有问题，当传递中文数据数据的时候，就会出现中文乱码问题，mysql里面的中文全部变成问号了。

解决方案

• Mysql数据库，数据表，数据字段采用统一编码UTF-8, 如 utf8_general_ci
• 客户端Java字符串转成json格式的时候先进行urlencode处理

  JSONObject jo = new JSONObject();
  //jo.accumulate("note", note);
  jo.accumulate("note", URLEncoder.encode(note));

• 服务器端PHP转换json格式后，插入数据库前先进行urldecode处理

  $data = array(
      'meta_key' => 'note',
      //'meta_value' => $params['note'],
      'meta_value' => urldecode($params['note']),
  );

• 经过以上的步骤处理，可完美解决中文乱码问题

Java PHP Json Mysql 中文乱码问题之解决，首发于润物无声。

2012年开始，百度空间的博文发布系统进行了一些调整，主要是变更了一些请求的API参数和URL地址，以及增加跨域检测，提高了安全性，所以旧的代码无法正常工作，更新过的可以正常工作的代码在本文的最后有下载链接。

主要变更点如下：

1. 百度空间的登录

   params.put("mem_pass", "on");

2. 添加博文类别

   params.put("spIsBlogCatAdd", "1");

3. 博文发布

   参数变更：params.put("previewImg", "");

   提交地址变更：private static final String SUBMIT_CREATBLOG_URL = "http://hi.baidu.com/" + Config.USERNAME + "/blog/submit/createblog";

4. 跨域检测

   httpPost.setRequestHeader("Referer", refURL);

代码下载

程序源码 BaiduCreateBlog(20120205)

关于Java程序自动发布文章到百度空间的程序更新，首发于润物无声。

Play是什么

Play是 一个Java Web框架 。针对Web开发，Play采用了“净室”方法，不会强加约束，例如：

兼容Servlet容器、支持JSP、兼容标准Java Web App布局、顺应Java和OO原则。

Play遵循Ruby on Rails的“Built-and-Deploy”模型，而不是更传统的“Package-and-Distribute”模型。

不需要公式化的类或XML配置文件。框架采用了全新的打包惯例，在适当的地方使用了静态代码。举例来说，控制器入口点是无状态的，它面向HTTP而非面向对象，因此可以用静态方法来实现。

Play基于无容器的PaaS模型。Play应用可以运行于本地，也可以无缝地部署到生产环境。这样一来就可以简化部署工作流，消除由环境差异导致的问题。
从架构角度来看，Play使用了Netty，这是一个由JBoss团队构建的非阻塞I/O协议库，它使用基于Continuation的编程模型，可以支持请求的异步处理。Play还实现了Share-Nothing模型，可以很方便地通过添加节点对应于程序进行水平扩展，有状态会话是无法做到这点的。

怎样使用Play

1. 安装 heroku 客户端开发环境，参见  Linux, Mac,  Windows.
2. 安装 git  客户端软件和配置 ssh key，参见 Mac，Windows 和 Linux
3. 安装 Play! version 1.2.3
4. 登录 Heroku :

   heroku auth:login

5. 创建一个 Play! app:

   play new play_hello_carey
   cd play_hello_carey

   

6. 本地运行 app :

   play run --%production

   

7. 建立 git repo:

   git init
   git add app conf lib public test
   git commit -m init

8. 在 Heroku 上建立一个新的 app :

   heroku create -s cedar

   

9. 上传 play_hello_carey app 到 Heroku:

   git push heroku master

10. 运行 app，浏览器中访问app网址 :

    heroku open

    

通过这个流程，相信大家可以知道怎样在Heroku上面部署安装基于Play框架的Java程序了。

参考文献

• getting-started-with-play-framework-on-heroku
• play-heroku

Heroku 上的 Play Framework（Java），首发于润物无声。

Heroku is a Polyglot Cloud Application Platform. Heroku provides us a way to run Ruby, Node.js, Clojure, and Java applications on a managed, scalable, and multi-tenant system. Heroku also provides numerous add-ons that help us make the shift from monolithic middleware to Cloud Components. Another way to say it is:

Heroku = Polyglot + Platform as a Service (PaaS) + Cloud Components

Heroku是一个支持多语言的云应用平台。 它为我们提供了一个支撑的环境来运行Ruby，Node.js，Clojure，和Java应用程序，并且是可扩展，多租户的系统。 Heroku还提供了众多的组件，帮助我们从单片中间件转移到云组件。另一种说法是：

Heroku = 多语种 + 平台作为服务（PaaS）+ 云组件

Heroku 上运行Java程序

Heroku can run any Java app that runs in OpenJDK 6. Today Heroku uses Maven to create a “slug” for Java apps. That slug can then be loaded onto one or more “dynos“. You can tell a dyno to execute / start a Java app from the command line and you can also use a “Procfile” to provide a command that will auto-start for each instance of a specific dyno type. Web dynos are able to listen on a port and will receive HTTP traffic through a load balancer that is automatically setup for each app. With that background knowledge, lets dive into code!

Heroku 的Java运行时环境为OpenJDK 6，通过用Maven来编译程序，然后将程序上传到云端，用命令行方式来启动执行Java应用程序，云端会根据HTTP流量自动调节负载平衡，并启动一个运行实例。

具体步骤如下：

1. 安装 heroku 客户端软件，参见  Linux，Mac 和  Windows
2. 安装 git  客户端软件和配置 ssh key，参见 Mac，Windows 和 Linux
3. 安装 Maven
4. 从命令行登入 Heroku :

   heroku auth:login
   依次输入Email和Password，如果是第一次登录的话会要求上传SSH key文件，选择yes就行，然后heroku会将这些信息保存在本地，以后登录就不需要再次输入了。

5. 建立一个新的工程目录:

   mkdir herokuhellojava
   cd herokuhellojava

6. 新建 Maven 配置文件 pom.xml:

   <?xml version="1.0" encoding="UTF-8"?>
   <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
       <modelVersion>4.0.0</modelVersion>
       <groupId>foo</groupId>
       <version>1.0-SNAPSHOT</version>
       <name>herokuhellojava</name>
       <artifactId>herokuhellojava</artifactId>
   </project>

7. 建立Java source 目录:

   mkdir -p src/main/java

8. 在 src/main/java 目录中新建立一个Java 源文件 Hello.java :

   public class Hello
   {
     public static void main(String[] args)
     {
       System.out.println("hello, Carey");
     }
   }

9. 编译工程项目:

   mvn compile

10. 本地运行Java程序:

    java -cp target/classes Hello
    程序输出 hello, Carey

11. 建立git本地repo，然后将 pom.xml 和 src 文件夹加入进去:

    git init
    git add pom.xml src
    git commit -m init

12. 利用cedar栈在Heroku上建立一个新的APP:

    heroku create -s cedar
    程序输出新建立的APP的信息，比如 stark-lightning-113

13. 把本地的java程序上传到Heroku:

    git push heroku master

    Heroku 会自动建立一个 与此APP对应的 slug .

14. 在 Heroku上远程运行java程序:

    heroku run "java -cp target/classes Hello"

    Heroku 会新建立一个 dyno 环境，装载此APP的 slug，然后运行该APP

    

到目前为止，你已经开始在云端运行Java程序了，虽然只是个简单的Demo程序，但是至少知道了整个部署和执行的过程，接下来要学习的东西还有很多很多。

下一步工作

• 阅读书籍 Heroku for Java Workbook
• 阅读文章 Heroku Dev Center
• 问题讨论 StackOverflow

参考文献

heroku-adds-java-support

Heroku 上的 Java 程序设计，首发于润物无声。

本文的基本思路如下：

1.  先把数据进行分组，即每一个地区一个组，例如

1898742 1898743 1898744 :云南曲靖

1894380 1894381 1894382 :吉林松原

2.  把电话号码进行排序，目的就是为了找到电话号码的区间，例如

1894815 --> 1899819 :广东珠海，

找到了一个区段，这样就不用把每个电话号码读存储下来， 只要存储一个区间就好，

这样可以大大节省存储空间

3. 设计新的存储格式，本文的程序采用如下方式存储

4. 归属地查询

根据用户输入的电话号码，利用二分查找法可快速定位到该记录在文件中的位置偏移，读出该记录中位置字符串的偏移值，进而查表即可找到归属地

程序设计，源码如下：

package com.carey.tel;
import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.RandomAccessFile;
import java.util.ArrayList;
import java.util.Collections;
import java.util.Date;
import java.util.HashMap;

public class JavaTelArea {
     private static JavaTelArea jta = null;
     private static final String INDEXDATAFILE = "tel.bin";
     private static Hearder cacheHearder = null;
     private static AreaCode cacheAreaCode = null;
     private static String cacheIndexFilePath = null;

     public static void main(String[] args) {
          JavaTelArea ctc = JavaTelArea.getInstance();
          //ctc.genIndexFile("e:\", "e:\telphone.txt");
          String indexPath = "e:\";

          long startTime = new Date().getTime();
          String searchNum = "13889650920";
          String res = ctc.searchTel(indexPath, searchNum);
          System.out.println(searchNum + " : " + res);
          System.out.println(System.currentTimeMillis() - startTime + "ms");

          startTime = new Date().getTime();
          searchNum = "+8613659867583";
          res = ctc.searchTel(indexPath, searchNum);
          System.out.println(searchNum + " : " + res);
          System.out.println(System.currentTimeMillis() - startTime + "ms");

          startTime = new Date().getTime();
          searchNum = "1301815";
          res = ctc.searchTel(indexPath, searchNum);
          System.out.println(searchNum + " : " + res);
          System.out.println(System.currentTimeMillis() - startTime + "ms");

          startTime = new Date().getTime();
          searchNum = "1301816";
          res = ctc.searchTel(indexPath, searchNum);
          System.out.println("没有预测");
          System.out.println(searchNum + " : " + res);
          System.out.println(System.currentTimeMillis() - startTime + "ms");

          startTime = new Date().getTime();
          searchNum = "1301816";
	  res = ctc.searchTel(indexPath, searchNum, true);
	  System.out.println("根据号码连贯性原理预测");
          System.out.println(searchNum + " : " + res);
          System.out.println(System.currentTimeMillis() - startTime + "ms");

          startTime = new Date().getTime();
          searchNum = "1301817";
          res = ctc.searchTel(indexPath, searchNum);
          System.out.println(searchNum + " : " + res);
          System.out.println(System.currentTimeMillis() - startTime + "ms");
    }

    private HashMap<Long, String> generateTestData() {
          HashMap<Long, String>
          telToAreaCode = new HashMap<Long, String>();
          telToAreaCode.put(1310944l, "新疆伊犁州");
          telToAreaCode.put(1301263l, "新疆伊犁州");
          telToAreaCode.put(1301264l, "新疆伊犁州");
          telToAreaCode.put(1301260l, "新疆伊犁州");
          telToAreaCode.put(955L, "海南");
          telToAreaCode.put(1320955l, "海南");
          telToAreaCode.put(1320957l, "海南");
          telToAreaCode.put(1300561L, "陕西商州");
          telToAreaCode.put(1300562L, "陕西商州");
          return telToAreaCode;
    }

    public static synchronized JavaTelArea getInstance() {
         if (jta == null) {
               jta = new JavaTelArea();
         }
         return jta;
    }

   /**	 * Generate Index File (tel.bin)	 * */
   private void genIndexFile(String indexFilePath, String souceFile) {
         ArrayList<String> strs = readFileToList(souceFile);
         HashMap<Long, String>
         telToArea = createTel2AreaHashMap(strs);
         writeDate(indexFilePath + INDEXDATAFILE, telToArea);
   }

   /**	 * read file content to String array list, every line one string.	 * */
   private ArrayList<String> readFileToList(String filePath) {
        final ArrayList<String>
        strLists = new ArrayList<String>();

        BufferedReader bReader = null;
        try {
              bReader = new BufferedReader(new InputStreamReader(new FileInputStream(filePath)));
              String str = bReader.readLine();
              while (str != null) {
                   strLists.add(str);
                   str = bReader.readLine();
              }
         } catch (Exception e) {
             e.printStackTrace();
         } finally {
           if (bReader != null) {
               try {
                     bReader.close();
               } catch (IOException e) {
                    e.printStackTrace();
               }
          }
       }
       return strLists;
    }

     /**	 * create telephone number to area hash map.	 * */
     HashMap<Long, String> createTel2AreaHashMap(ArrayList<String> strs) {
           final HashMap<Long, String>
           telToArea = new HashMap<Long, String>();

           String[] tels = null;
           int len = 0;
           String strArea = null;
           for (String string : strs) {
               tels = string.split(" ");
               len = tels.length;
               strArea = tels[len - 1].substring(1);

               for (int i = 0; i < len - 1; i++) {
                    telToArea.put(Long.valueOf(tels[i]), strArea);
               }
           }
         return telToArea;
    }

    /**	 * combined the adjacent Records.	 * */
    private void combinedRecords(ArrayList<Record> records, Record newRecord) {
          int size = records.size();
          if (size > 0&& records.get(size - 1).areacodeIndex == newRecord.areacodeIndex) {
               // combined
              Record lastRecord = records.get(size - 1);
              lastRecord.numCnt = (int) (newRecord.baseTelNum - lastRecord.baseTelNum) + newRecord.numCnt;
         } else {
              records.add(newRecord);
         }
    }

   /**	 * write index info to file.	 * */
   private void writeDate(String filePath, HashMap<Long, String> telToAreaCode) {
       // 1. get all area info
       ArrayList<String> tmpAreaCodes = new ArrayList<String>(telToAreaCode.values());
       ArrayList<String> strAreaCodes = new ArrayList<String>();
       for (String str : tmpAreaCodes) {
            if (!strAreaCodes.contains(str)) {
                    strAreaCodes.add(str);
            }
       }
       tmpAreaCodes.clear();
       tmpAreaCodes = null;

       StringBuffer sb = new StringBuffer();
       for (String str : strAreaCodes) {
                 sb.append(str + ",");
       }
       sb.deleteCharAt(sb.length() - 1);

       AreaCode areaCode = new AreaCode(sb.toString());
       areaCode.print();

       // 2. Sort HashMap and combined the adjacent telephone number
       ArrayList<Long> telNunms = new ArrayList<Long>(telToAreaCode.keySet());
       Collections.sort(telNunms);
       ArrayList<Record> records = new ArrayList<Record>();
       long baseNum = 0;
       String baseArea = null;
       int numCnt = 0;
       for (Long tm : telNunms) {
             if (numCnt == 0) {
                    baseNum = tm;
                    baseArea = telToAreaCode.get(tm);
                    numCnt = 1;
             } else {
                    if (tm == baseNum + numCnt && baseArea.equals(telToAreaCode.get(tm))) {
			  numCnt++;
                    } else {
                         combinedRecords(records, new Record(baseNum, numCnt,	strAreaCodes.indexOf(baseArea)));
                         baseNum = tm;
                         baseArea = telToAreaCode.get(tm);
                         numCnt = 1;
                    }
             }
          }
         combinedRecords(records,	new Record(baseNum, numCnt, strAreaCodes.indexOf(baseArea)));		

         // for (Record record : records) {
               // record.print();
         // }

         // 3. Write data to the file
         RandomAccessFile raf = null;
         try {
                raf = new RandomAccessFile(filePath, "rw");
                raf.seek(0);

                Hearder hearder = new Hearder();
                hearder.firstRecordOffset = hearder.Size() + areaCode.Size();
                hearder.lastRecordOffset = hearder.firstRecordOffset	+ (records.size() - 1) * records.get(0).Size();
                hearder.print();
                hearder.write(raf);

                areaCode.write(raf);

                for (Record record : records) {
                       record.write(raf);
                }
          } catch (Exception e) {
              e.printStackTrace();
          } finally {
              if (raf != null) {
                    try {
                           raf.close();
                     } catch (IOException e) {
                            e.printStackTrace();
                     }
              }
          }
    }

   class Hearder {
         int firstRecordOffset;
         int lastRecordOffset;

         public int Size() {
                 return (Integer.SIZE + Integer.SIZE) / Byte.SIZE;
         }

         public void write(RandomAccessFile raf) throws IOException {
                raf.writeInt(this.firstRecordOffset);
                raf.writeInt(this.lastRecordOffset);
         }

        public void read(RandomAccessFile raf) throws IOException {
               this.firstRecordOffset = raf.readInt();
               this.lastRecordOffset = raf.readInt();
        }

        public void print() {
                System.out.println("===== Hearder ===== ");
                System.out.println("[" + firstRecordOffset + " , "	 + lastRecordOffset + "]");
        }
    }

   class AreaCode {
          private String areacode;
          private String[] codes;

          public AreaCode() {
               this("");
          }

          public AreaCode(String areacode) {
               this.areacode = areacode;
               this.codes = null;
          }

          public int Size() {
                 return areacode.getBytes().length + (Integer.SIZE / Byte.SIZE);
          }

          public void print() {
                System.out.println("===== AreaCode ===== ");
                System.out.println("[" + areacode.getBytes().length + "]" + areacode);
          }

         public void write(RandomAccessFile raf) throws IOException {
		raf.writeInt(areacode.getBytes().length);
                raf.write(this.areacode.getBytes());
         }

         public void read(RandomAccessFile raf) throws IOException {
                byte[] bytes = new byte[raf.readInt()];
                raf.read(bytes);
                this.areacode = new String(bytes);
         }

         public String getCodeByIndex(int index) {
             if (this.codes == null) {
                   this.codes = this.areacode.split(",");
             }
             return (index < 0 || this.codes == null || index >= this.codes.length) ? null	 : this.codes[index];
        }
}

class Record {
       long baseTelNum;
       int numCnt;
       int areacodeIndex;

       public Record() {
            this(0, 0, 0);
       }

       public Record(long baseTelNum, int numCnt, int areacodeIndex) {
             this.baseTelNum = baseTelNum;
             this.numCnt = numCnt;
             this.areacodeIndex = areacodeIndex;
       }

       public void print() {
             System.out.println("===== Record ===== ");
             System.out.println("<" + baseTelNum + "> <" + numCnt + "> <" + areacodeIndex + ">");
       }

      public int Size() {
             return (Long.SIZE + Integer.SIZE) / Byte.SIZE;
      }

      public void write(RandomAccessFile raf) throws IOException {
           raf.writeLong(this.baseTelNum);
           int tmp = this.numCnt << 16;
           tmp += 0xFFFF & this.areacodeIndex;
           raf.writeInt(tmp);
      }

     public void read(RandomAccessFile raf) throws IOException {
          this.baseTelNum = raf.readLong();
          int tmp = raf.readInt();
          this.numCnt = tmp >> 16;
          this.areacodeIndex = 0xFFFF & tmp;
     }

     public int inWhich(long telNum) {
         if (telNum < this.baseTelNum) {
               return -1;
         } else if (telNum >= this.baseTelNum + this.numCnt) {
               return 1;
         } else {
               return 0;
         }
    }
 }

  public String searchTel(String indexFilePath, String telNum) {
          return searchTel(indexFilePath, telNum, false);
  }

  /**	 * search	 * */
  public String searchTel(String indexFilePath, String telNum, boolean forecast) {
	StringBuffer sb = new StringBuffer(telNum);

	// +
	if (sb.charAt(0) == '+') {
		sb.deleteCharAt(0);
	}

	// 86
	if (sb.charAt(0) == '8' && sb.charAt(1) == '6') {
		sb.delete(0, 2);
	}

	// 以0开头，是区号
	if (sb.charAt(0) == '0') {
		sb.deleteCharAt(0);
		// 首先按照4位区号查询，若查询为空，再按3位区号查询
		if (sb.length() >= 3) {
			sb.delete(3, sb.length());
		} 

		String dial = searchTel(indexFilePath, Long.valueOf(sb.toString()),false);
			
		if (dial != null) {
			return dial;
		}
			
		if (sb.length() >= 2) {
			sb.delete(2, sb.length());
		}
	}
	// 以1开头，是手机号或者服务行业号码
	else if (sb.charAt(0) == '1') {
		// 首先按照手机号码查询，若查询为空，再按特殊号码查询
			
		if (sb.length() > 7) {
			String dial = searchTel(indexFilePath, Long.valueOf(sb.substring(0, 8)),false);
				
			if (dial != null) {
				return dial;
			}
				
			dial = searchTel(indexFilePath, Long.valueOf(sb.toString()),false);
				
			if (dial != null) {
				return dial;
			}
				
			// 只需要保留7位号码就ok了，多余的删掉
			if (sb.length() > 7) {
				sb.delete(7, sb.length());
			}
		} else {
			//小于7位，最有可能是服务号码
			//do nothing.
		}
	}
	// 以其他数字开头，这也不知道是啥号码了
	else {
		//do nothing.
	}

	return searchTel(indexFilePath, Long.valueOf(sb.toString()), forecast);
  }

 private String searchTel(String indexFilePath, long telNum, boolean forecast) {
          RandomAccessFile raf = null;
          try {
             raf = new RandomAccessFile(indexFilePath + INDEXDATAFILE, "r");
             if (cacheIndexFilePath == null || !cacheIndexFilePath.equals(indexFilePath)) {
                cacheIndexFilePath = indexFilePath;
                cacheHearder = new Hearder();
                cacheHearder.read(raf);
                cacheHearder.print();

                cacheAreaCode = new AreaCode();
                cacheAreaCode.read(raf);
                cacheAreaCode.print();
             }

            int index = lookUP(raf, cacheHearder.firstRecordOffset, cacheHearder.lastRecordOffset, telNum, forecast);
            return cacheAreaCode.getCodeByIndex(index);
         } catch (Exception e) {
              e.printStackTrace();
         } finally {
              if (raf != null) {
                  try {
                         raf.close();
                  } catch (IOException e) {
                       e.printStackTrace();
                  }
               }
         }

      return null;
  }

  private int lookUP(RandomAccessFile raf, long startpos, long endpos, long looknum, boolean forecast) throws IOException {
      Record record = new Record();
      long seekpos = 0;

      do {
            seekpos = startpos + (endpos - startpos) / record.Size() / 2 * record.Size();
            raf.seek(seekpos);
            record.read(raf);

           if (record.inWhich(looknum) > 0) {
                 startpos = seekpos + record.Size();
           } else if (record.inWhich(looknum) < 0) {
                 endpos = seekpos - record.Size();
           } else {
                 return record.areacodeIndex;
           }
      } while (startpos <= endpos);

     if (forecast) {
            return record.areacodeIndex;
     } else {
           return -1;
     }
  }
}

程序运行情况如下：

==== Hearder =====
[4554 , 605622]
===== AreaCode ===== 
[4542]北福建南平,福建三明,海果洛,青海海南,...
13889650920 : 辽宁大连
20ms
+8613659867583 : 湖北武汉
2ms
1301815 : 四川泸州
2ms
没有预测1301816 : null
2ms
根据号码连贯性原理预测1301816 : 四川泸州
1ms
1301817 : 四川宜宾
2ms

可以看到，除了第一次查询的时候要加载索引文件大约耗时20ms，以后的查询基本都在1ms，速度非常快了！！！

本程序的测试data文件下载telinfo

电话归属地查询之Android解决方案，首发于润物无声。

Java 安全

安全性是Java应用程序的非功能性需求的重要组成部分，如同其它的非功能性需求一样，安全性很容易被开发人员所忽略。当然，对于Java EE的开发人员来说，安全性的话题可能没那么陌生，用户认证和授权可能是绝大部分Web应用都有的功能。类似Spring Security这样的框架，也使得开发变得更加简单。本文并不会讨论Web应用的安全性，而是介绍Java安全一些底层和基本的内容。

认证
用户认证是应用安全性的重要组成部分，其目的是确保应用的使用者具有合法的身份。
Java安全中使用术语主体（Subject）来表示访问请求的来源。一个主体可以是任何的实体。一个主体可以有多个不同的身份标识（Principal）。比如一个应用的用户这类主体，就可以有用户名、身份证号码和手机号码等多种身份标识。除了身份标识之外，一个主体还可以有公开或是私有的安全相关的凭证（Credential），包括密码和密钥等。

典型的用户认证过程是通过登录操作来完成的。在登录成功之后，一个主体中就具备了相应的身份标识。Java提供了一个可扩展的登录框架，使得应用开发人员可以很容易的定制和扩展与登录相关的逻辑。登录的过程由LoginContext启动。在创建LoginContext的时候需要指定一个登录配置（Configuration）的名称。该登录配置中包含了登录所需的多个LoginModule的信息。每个LoginModule实现了一种登录方式。当调用LoginContext的login方法的时候，所配置的每个LoginModule会被调用来执行登录操作。如果整个登录过程成功，则通过getSubject方法就可以获取到包含了身份标识信息的主体。开发人员可以实现自己的LoginModule来定制不同的登录逻辑。

每个LoginModule的登录方式由两个阶段组成。第一个阶段是在login方法的实现中。这个阶段用来进行必要的身份认证，可能需要获取用户的输入，以及通过数据库、网络操作或其它方式来完成认证。当认证成功之后，把必要的信息保存起来。如果认证失败，则抛出相关的异常。第二阶段是在commit或abort方法中。由于一个登录过程可能涉及到多个LoginModule。LoginContext会根据每个LoginModule的认证结果以及相关的配置信息来确定本次登录是否成功。LoginContext用来判断的依据是每个LoginModule对整个登录过程的必要性，分成必需、必要、充分和可选这四种情况。如果登录成功，则每个LoginModule的commit方法会被调用，用来把身份标识关联到主体上。如果登录失败，则LoginModule 的abort方法会被调用，用来清除之前保存的认证相关信息。

在LoginModule进行认证的过程中，如果需要获取用户的输入，可以通过CallbackHandler和对应的Callback来完成。每个Callback可以用来进行必要的数据传递。典型的启动登录的过程如下：

public Subject login() throws LoginException {    
    TextInputCallbackHandler callbackHandler = new TextInputCallbackHandler();    
    LoginContext lc = new LoginContext("SmsApp", callbackHandler);    
    lc.login();    
    return lc.getSubject();
}

这里的SmsApp是登录配置的名称，可以在配置文件中找到。该配置文件的内容也很简单。

SmsApp {    
    security.login.SmsLoginModule required;
};

这里声明了使用security.login.SmsLoginModule这个登录模块，而且该模块是必需的。配置文件可以通过启动程序时的参数java.security.auth.login.config来指定，或修改JVM的默认设置。下面看看SmsLoginModule的核心方法login和commit。

public boolean login() throws LoginException {    
    TextInputCallback phoneInputCallback = new TextInputCallback("Phone number: ");    
    TextInputCallback smsInputCallback = new TextInputCallback("Code: ");    
    try {        
        handler.handle(new Callback[] {phoneInputCallback, smsInputCallback});    
    } catch (Exception e) {        
        throw new LoginException(e.getMessage());    
    }     
    String code = smsInputCallback.getText();    
    boolean isValid = code.length() > 3; //此处只是简单的进行验证。   
    if (isValid) {        
        phoneNumber = phoneInputCallback.getText();    
    }    
    return isValid;
}
public boolean commit() throws LoginException {    
    if (phoneNumber != null) {        
    subject.getPrincipals().add(new PhonePrincipal(phoneNumber));       
    return true;    
}    
    return false;
}

这里使用了两个TextInputCallback来获取用户的输入。当用户输入的编码有效的时候，就把相关的信息记录下来，此处是用户的手机号码。在commit方法中，就把该手机号码作为用户的身份标识与主体关联起来。

权限控制
在验证了访问请求来源的合法身份之后，另一项工作是验证其是否具有相应的权限。权限由Permission及其子类来表示。每个权限都有一个名称，该名称的含义与权限类型相关。某些权限有与之对应的动作列表。比较典型的是文件操作权限FilePermission，它的名称是文件的路径，而它的动作列表则包括读取、写入和执行等。Permission类中最重要的是implies方法，它定义了权限之间的包含关系，是进行验证的基础。

权限控制包括管理和验证两个部分。管理指的是定义应用中的权限控制策略，而验证指的则是在运行时刻根据策略来判断某次请求是否合法。策略可以与主体关联，也可以没有关联。策略由Policy来表示，JDK提供了基于文件存储的基本实现。开发人员也可以提供自己的实现。在应用运行过程中，只可能有一个Policy处于生效的状态。验证部分的具体执行者是AccessController，其中的checkPermission方法用来验证给定的权限是否被允许。在应用中执行相关的访问请求之前，都需要调用checkPermission方法来进行验证。如果验证失败的话，该方法会抛出AccessControlException异常。 JVM中内置提供了一些对访问关键部分内容的访问控制检查，不过只有在启动应用的时通过参数-Djava.security.manager启用了安全管理器之后才能生效，并与策略相配合。

与访问控制相关的另外一个概念是特权动作。特权动作只关心动作本身所要求的权限是否具备，而并不关心调用者是谁。比如一个写入文件的特权动作，它只要求对该文件有写入权限即可，并不关心是谁要求它执行这样的动作。特权动作根据是否抛出受检异常，分为PrivilegedAction和PrivilegedExceptionAction。这两个接口都只有一个run方法用来执行相关的动作，也可以向调用者返回结果。通过AccessController的doPrivileged方法就可以执行特权动作。

Java安全使用了保护域的概念。每个保护域都包含一组类、身份标识和权限，其意义是在当访问请求的来源是这些身份标识的时候，这些类的实例就自动具有给定的这些权限。保护域的权限既可以是固定，也可以根据策略来动态变化。ProtectionDomain类用来表示保护域，它的两个构造方法分别用来支持静态和动态的权限。一般来说，应用程序通常会涉及到系统保护域和应用保护域。不少的方法调用可能会跨越多个保护域的边界。因此，在AccessController进行访问控制验证的时候，需要考虑当前操作的调用上下文，主要指的是方法调用栈上不同方法所属于的不同保护域。这个调用上下文一般是与当前线程绑定在一起的。通过AccessController的getContext方法可以获取到表示调用上下文的AccessControlContext对象，相当于访问控制验证所需的调用栈的一个快照。在有些情况下，会需要传递此对象以方便在其它线程中进行访问控制验证。

考虑下面的权限验证代码：

Subject subject = new Subject();
ViewerPrincipal principal = new ViewerPrincipal("Alex");
subject.getPrincipals().add(principal);
Subject.doAsPrivileged(subject, new PrivilegedAction<Object>() {    
    public Object run() {       
        new Viewer().view();        
        return null;   
    }
}, null);

这里创建了一个新的Subject对象并关联上身份标识。通常来说，这个过程是由登录操作来完成的。通过Subject的doAsPrivileged方法就可以执行一个特权动作。Viewer对象的view方法会使用AccessController来检查是否具有相应的权限。策略配置文件的内容也比较简单，在启动程序的时候通过参数java.security.auth.policy指定文件路径即可。

grant Principal security.access.ViewerPrincipal "Alex" {
    permission security.access.ViewPermission "CONFIDENTIAL";
}; //这里把名称为CONFIDENTIAL的ViewPermission授权给了身份标识为Alex的主体。

加密、解密与签名
构建安全的Java应用离不开加密和解密。Java的密码框架采用了常见的服务提供者架构，以提供所需的可扩展性和互操作性。该密码框架提供了一系列常用的服务，包括加密、数字签名和报文摘要等。这些服务都有服务提供者接口（SPI），服务的实现者只需要实现这些接口，并注册到密码框架中即可。比如加密服务Cipher的SPI接口就是CipherSpi。每个服务都可以有不同的算法来实现。密码框架也提供了相应的工厂方法用来获取到服务的实例。比如想使用采用MD5算法的报文摘要服务，只需要调用MessageDigest.getInstance("MD5")即可。

加密和解密过程中并不可少的就是密钥（Key）。加密算法一般分成对称和非对称两种。对称加密算法使用同一个密钥进行加密和解密；而非对称加密算法使用一对公钥和私钥，一个加密的时候，另外一个就用来解密。不同的加密算法，有不同的密钥。对称加密算法使用的是SecretKey，而非对称加密算法则使用PublicKey和PrivateKey。与密钥Key对应的另一个接口是KeySpec，用来描述不同算法的密钥的具体内容。比如一个典型的使用对称加密的方式如下：

KeyGenerator generator = KeyGenerator.getInstance("DES");
SecretKey key = generator.generateKey();
saveFile("key.data", key.getEncoded());
Cipher cipher = Cipher.getInstance("DES");
cipher.init(Cipher.ENCRYPT_MODE, key);
String text = "Hello World";
byte[] encrypted = cipher.doFinal(text.getBytes());
saveFile("encrypted.bin", encrypted);

加密的时候首先要生成一个密钥，再由Cipher服务来完成。可以把密钥的内容保存起来，方便传递给需要解密的程序。

byte[] keyData = getData("key.data");
SecretKeySpec keySpec = new SecretKeySpec(keyData, "DES");
Cipher cipher = Cipher.getInstance("DES");
cipher.init(Cipher.DECRYPT_MODE, keySpec);
byte[] data = getData("encrypted.bin");
byte[] result = cipher.doFinal(data);

解密的时候先从保存的文件中得到密钥编码之后的内容，再通过SecretKeySpec获取到密钥本身的内容，再进行解密。

报文摘要的目的在于防止信息被有意或无意的修改。通过对原始数据应用某些算法，可以得到一个校验码。当收到数据之后，只需要应用同样的算法，再比较校验码是否一致，就可以判断数据是否被修改过。相对原始数据来说，校验码长度更小，更容易进行比较。消息认证码（Message Authentication Code）与报文摘要类似，不同的是计算的过程中加入了密钥，只有掌握了密钥的接收者才能验证数据的完整性。

使用公钥和私钥就可以实现数字签名的功能。某个发送者使用私钥对消息进行加密，接收者使用公钥进行解密。由于私钥只有发送者知道，当接收者使用公钥解密成功之后，就可以判定消息的来源肯定是特定的发送者。这就相当于发送者对消息进行了签名。数字签名由Signature服务提供，签名和验证的过程都比较直接。

Signature signature = Signature.getInstance("SHA1withDSA");
KeyPairGenerator keyGenerator = KeyPairGenerator.getInstance("DSA");
KeyPair keyPair = keyGenerator.generateKeyPair();
PrivateKey privateKey = keyPair.getPrivate();
signature.initSign(privateKey);
byte[] data = "Hello World".getBytes();
signature.update(data);
byte[] signatureData = signature.sign(); //得到签名
PublicKey publicKey = keyPair.getPublic();
signature.initVerify(publicKey);
signature.update(data);
boolean result = signature.verify(signatureData); //进行验证

验证数字签名使用的公钥可以通过文件或证书的方式来进行发布。

安全套接字连接
在各种数据传输方式中，网络传输目前使用较广，但是安全隐患也更多。安全套接字连接指的是对套接字连接进行加密。加密的时候可以选择对称加密算法。但是如何在发送者和接收者之间安全的共享密钥，是个很麻烦的问题。如果再用加密算法来加密密钥，则成为了一个循环问题。非对称加密算法则适合于这种情况。私钥自己保管，公钥则公开出去。发送数据的时候，用私钥加密，接收者用公开的公钥解密；接收数据的时候，则正好相反。这种做法解决了共享密钥的问题，但是另外的一个问题是如何确保接收者所得到的公钥确实来自所声明的发送者，而不是伪造的。为此，又引入了证书的概念。证书中包含了身份标识和对应的公钥。证书由用户所信任的机构签发，并用该机构的私钥来加密。在有些情况下，某个证书签发机构的真实性会需要由另外一个机构的证书来证明。通过这种证明关系，会形成一个证书的链条。而链条的根则是公认的值得信任的机构。只有当证书链条上的所有证书都被信任的时候，才能信任证书中所给出的公钥。

日常开发中比较常接触的就是HTTPS，即安全的HTTP连接。大部分用Java程序访问采用HTTPS网站时出现的错误都与证书链条相关。有些网站采用的不是由正规安全机构签发的证书，或是证书已经过期。如果必须访问这样的HTTPS网站的话，可以提供自己的套接字工厂和主机名验证类来绕过去。另外一种做法是通过keytool工具把证书导入到系统的信任证书库之中。

URL url = new URL("https://localhost:8443");
SSLContext context = SSLContext.getInstance("TLS");
context.init(new KeyManager[] {}, new TrustManager[] {new MyTrustManager()}, new SecureRandom());HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());
connection.setHostnameVerifier(new MyHostnameVerifier());

这里的MyTrustManager实现了X509TrustManager接口，但是所有方法都是默认实现。而MyHostnameVerifier实现了HostnameVerifier接口，其中的verify方法总是返回true。

参考资料

• Java安全体系结构
• Java密码框架（JCA）参考指南
• Java认证和授权服务（JAAS）参考指南
• Java安全套接字扩展（JSSE）参考指南

Java对象序列化与RMI

对于一个存在于Java虚拟机中的对象来说，其内部的状态只保持在内存中。JVM停止之后，这些状态就丢失了。在很多情况下，对象的内部状态是需要被持久化下来的。提到持久化，最直接的做法是保存到文件系统或是数据库之中。这种做法一般涉及到自定义存储格式以及繁琐的数据转换。对象关系映射（Object-relational mapping）是一种典型的用关系数据库来持久化对象的方式，也存在很多直接存储对象的对象数据库。对象序列化机制（object serialization）是Java语言内建的一种对象持久化方式，可以很容易的在JVM中的活动对象和字节数组（流）之间进行转换。除了可以很简单的实现持久化之外，序列化机制的另外一个重要用途是在远程方法调用中，用来对开发人员屏蔽底层实现细节。

基本的对象序列化
由于Java提供了良好的默认支持，实现基本的对象序列化是件比较简单的事。待序列化的Java类只需要实现Serializable接口即可。Serializable仅是一个标记接口，并不包含任何需要实现的具体方法。实现该接口只是为了声明该Java类的对象是可以被序列化的。实际的序列化和反序列化工作是通过ObjectOuputStream和ObjectInputStream来完成的。ObjectOutputStream的writeObject方法可以把一个Java对象写入到流中，ObjectInputStream的readObject方法可以从流中读取一个Java对象。在写入和读取的时候，虽然用的参数或返回值是单个对象，但实际上操纵的是一个对象图，包括该对象所引用的其它对象，以及这些对象所引用的另外的对象。Java会自动帮你遍历对象图并逐个序列化。除了对象之外，Java中的基本类型和数组也是可以通过 ObjectOutputStream和ObjectInputStream来序列化的。

try {
    User user = new User("Alex", "Cheng");
    ObjectOutputStream output = new ObjectOutputStream(new FileOutputStream("user.bin"));
    output.writeObject(user);
    output.close();
} catch (IOException e) {
    e.printStackTrace();
}

try {
    ObjectInputStream input = new ObjectInputStream(new FileInputStream("user.bin"));
    User user = (User) input.readObject();
    System.out.println(user);
} catch (Exception e) {
    e.printStackTrace();
}

上面的代码给出了典型的把Java对象序列化之后保存到磁盘上，以及从磁盘上读取的基本方式。 User类只是声明了实现Serializable接口。

在默认的序列化实现中，Java对象中的非静态和非瞬时域都会被包括进来，而与域的可见性声明没有关系。这可能会导致某些不应该出现的域被包含在序列化之后的字节数组中，比如密码等隐私信息。由于Java对象序列化之后的格式是固定的，其它人可以很容易的从中分析出其中的各种信息。对于这种情况，一种解决办法是把域声明为瞬时的，即使用transient关键词。另外一种做法是添加一个serialPersistentFields? 域来声明序列化时要包含的域。从这里可以看到在Java序列化机制中的这种仅在书面层次上定义的契约。声明序列化的域必须使用固定的名称和类型。在后面还可以看到其它类似这样的契约。虽然Serializable只是一个标记接口，但它其实是包含有不少隐含的要求。下面的代码给出了 serialPersistentFields的声明示例，即只有firstName这个域是要被序列化的。

private static final ObjectStreamField[] serialPersistentFields = { 
    new ObjectStreamField("firstName", String.class) 
};

自定义对象序列化
基本的对象序列化机制让开发人员可以在包含哪些域上进行定制。如果想对序列化的过程进行更加细粒度的控制，就需要在类中添加writeObject和对应的 readObject方法。这两个方法属于前面提到的序列化机制的隐含契约的一部分。在通过ObjectOutputStream的 writeObject方法写入对象的时候，如果这个对象的类中定义了writeObject方法，就会调用该方法，并把当前 ObjectOutputStream对象作为参数传递进去。writeObject方法中一般会包含自定义的序列化逻辑，比如在写入之前修改域的值，或是写入额外的数据等。对于writeObject中添加的逻辑，在对应的readObject中都需要反转过来，与之对应。

在添加自己的逻辑之前，推荐的做法是先调用Java的默认实现。在writeObject方法中通过ObjectOutputStream的defaultWriteObject来完成，在readObject方法则通过ObjectInputStream的defaultReadObject来实现。下面的代码在对象的序列化流中写入了一个额外的字符串。

private void writeObject(ObjectOutputStream output) throws IOException {
    output.defaultWriteObject();
    output.writeUTF("Hello World");
}
private void readObject(ObjectInputStream input) throws IOException, ClassNotFoundException {
    input.defaultReadObject();
    String value = input.readUTF();
    System.out.println(value);
}

序列化时的对象替换
在有些情况下，可能会希望在序列化的时候使用另外一个对象来代替当前对象。其中的动机可能是当前对象中包含了一些不希望被序列化的域，比如这些域都是从另外一个域派生而来的；也可能是希望隐藏实际的类层次结构；还有可能是添加自定义的对象管理逻辑，如保证某个类在JVM中只有一个实例。相对于把无关的域都设成transient来说，使用对象替换是一个更好的选择，提供了更多的灵活性。替换对象的作用类似于Java EE中会使用到的传输对象（Transfer Object）。

考虑下面的例子，一个订单系统中需要把订单的相关信息序列化之后，通过网络来传输。订单类Order引用了客户类Customer。在默认序列化的情况下，Order类对象被序列化的时候，其引用的Customer类对象也会被序列化，这可能会造成用户信息的泄露。对于这种情况，可以创建一个另外的对象来在序列化的时候替换当前的Order类的对象，并把用户信息隐藏起来。

private static class OrderReplace implements Serializable {
    private static final long serialVersionUID = 4654546423735192613L;
    private String orderId;
    public OrderReplace(Order order) {
        this.orderId = order.getId();
    }
    private Object readResolve() throws ObjectStreamException {
        //根据orderId查找Order对象并返回
    }
}

这个替换对象类OrderReplace只保存了Order的ID。在Order类的writeReplace方法中返回了一个OrderReplace对象。这个对象会被作为替代写入到流中。同样的，需要在OrderReplace类中定义一个readResolve方法，用来在读取的时候再转换回 Order类对象。这样对调用者来说，替换对象的存在就是透明的。

private Object writeReplace() throws ObjectStreamException {
    return new OrderReplace(this);
}

序列化与对象创建
在通过ObjectInputStream的readObject方法读取到一个对象之后，这个对象是一个新的实例，但是其构造方法是没有被调用的，其中的域的初始化代码也没有被执行。对于那些没有被序列化的域，在新创建出来的对象中的值都是默认的。也就是说，这个对象从某种角度上来说是不完备的。这有可能会造成一些隐含的错误。调用者并不知道对象是通过一般的new操作符来创建的，还是通过反序列化所得到的。解决的办法就是在类的readObject方法里面，再执行所需的对象初始化逻辑。对于一般的Java类来说，构造方法中包含了初始化的逻辑。可以把这些逻辑提取到一个方法中，在readObject方法中调用此方法。

版本更新
把一个Java对象序列化之后，所得到的字节数组一般会保存在磁盘或数据库之中。在保存完成之后，有可能原来的Java类有了更新，比如添加了额外的域。这个时候从兼容性的角度出发，要求仍然能够读取旧版本的序列化数据。在读取的过程中，当ObjectInputStream发现一个对象的定义的时候，会尝试在当前JVM中查找其Java类定义。这个查找过程不能仅根据Java类的全名来判断，因为当前JVM中可能存在名称相同，但是含义完全不同的Java 类。这个对应关系是通过一个全局惟一标识符serialVersionUID来实现的。通过在实现了Serializable接口的类中定义该域，就声明了该Java类的一个惟一的序列化版本号。JVM会比对从字节数组中得出的类的版本号，与JVM中查找到的类的版本号是否一致，来决定两个类是否是兼容的。对于开发人员来说，需要记得的就是在实现了Serializable接口的类中定义这样的一个域，并在版本更新过程中保持该值不变。当然，如果不希望维持这种向后兼容性，换一个版本号即可。该域的值一般是综合Java类的各个特性而计算出来的一个哈希值，可以通过Java提供的serialver命令来生成。在Eclipse中，如果Java类实现了Serializable接口，Eclipse会提示并帮你生成这个serialVersionUID。

在类版本更新的过程中，某些操作会破坏向后兼容性。如果希望维持这种向后兼容性，就需要格外的注意。一般来说，在新的版本中添加东西不会产生什么问题，而去掉一些域则是不行的。

序列化安全性
前面提到，Java对象序列化之后的内容格式是公开的。所以可以很容易的从中提取出各种信息。从实现的角度来说，可以从不同的层次来加强序列化的安全性。

• 对序列化之后的流进行加密。这可以通过CipherOutputStream来实现。
• 实现自己的writeObject和readObject方法，在调用defaultWriteObject之前，先对要序列化的域的值进行加密处理。
• 使用一个SignedObject或SealedObject来封装当前对象，用SignedObject或SealedObject进行序列化。
• 在从流中进行反序列化的时候，可以通过ObjectInputStream的registerValidation方法添加ObjectInputValidation接口的实现，用来验证反序列化之后得到的对象是否合法。

RMI
RMI（Remote Method Invocation）是Java中的远程过程调用（Remote Procedure Call，RPC）实现，是一种分布式Java应用的实现方式。它的目的在于对开发人员屏蔽横跨不同JVM和网络连接等细节，使得分布在不同JVM上的对象像是存在于一个统一的JVM中一样，可以很方便的互相通讯。之所以在介绍对象序列化之后来介绍RMI，主要是因为对象序列化机制使得RMI非常简单。调用一个远程服务器上的方法并不是一件困难的事情。开发人员可以基于Apache MINA或是Netty这样的框架来写自己的网络服务器，亦或是可以采用REST架构风格来编写HTTP服务。但这些解决方案中，不可回避的一个部分就是数据的编排和解排（marshal/unmarshal）。需要在Java对象和传输格式之间进行互相转换，而且这一部分逻辑是开发人员无法回避的。RMI的优势在于依靠Java序列化机制，对开发人员屏蔽了数据编排和解排的细节，要做的事情非常少。JDK 5之后，RMI通过动态代理机制去掉了早期版本中需要通过工具进行代码生成的繁琐方式，使用起来更加简单。

RMI采用的是典型的客户端-服务器端架构。首先需要定义的是服务器端的远程接口，这一步是设计好服务器端需要提供什么样的服务。对远程接口的要求很简单，只需要继承自RMI中的Remote接口即可。Remote和Serializable一样，也是标记接口。远程接口中的方法需要抛出RemoteException。定义好远程接口之后，实现该接口即可。如下面的Calculator是一个简单的远程接口。

public interface Calculator extends Remote {
    String calculate(String expr) throws RemoteException;
}

实现了远程接口的类的实例称为远程对象。创建出远程对象之后，需要把它注册到一个注册表之中。这是为了客户端能够找到该远程对象并调用。

public class CalculatorServer implements Calculator {
    public String calculate(String expr) throws RemoteException {
        return expr;
    }
    public void start() throws RemoteException, AlreadyBoundException {
        Calculator stub = (Calculator) UnicastRemoteObject.exportObject(this, 0);
        Registry registry = LocateRegistry.getRegistry();
        registry.rebind("Calculator", stub);
    }
}

CalculatorServer是远程对象的Java类。在它的start方法中通过UnicastRemoteObject的exportObject把当前对象暴露出来，使得它可以接收来自客户端的调用请求。再通过Registry的rebind方法进行注册，使得客户端可以查找到。

客户端的实现就是首先从注册表中查找到远程接口的实现对象，再调用相应的方法即可。实际的调用虽然是在服务器端完成的，但是在客户端看来，这个接口中的方法就好像是在当前JVM中一样。这就是RMI的强大之处。

public class CalculatorClient {
    public void calculate(String expr) {
        try {
            Registry registry = LocateRegistry.getRegistry("localhost");
            Calculator calculator = (Calculator) registry.lookup("Calculator");
            String result = calculator.calculate(expr);
            System.out.println(result);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

在运行的时候，需要首先通过rmiregistry命令来启动RMI中用到的注册表服务器。

为了通过Java的序列化机制来进行传输，远程接口中的方法的参数和返回值，要么是Java的基本类型，要么是远程对象，要么是实现了 Serializable接口的Java类。当客户端通过RMI注册表找到一个远程接口的时候，所得到的其实是远程接口的一个动态代理对象。当客户端调用其中的方法的时候，方法的参数对象会在序列化之后，传输到服务器端。服务器端接收到之后，进行反序列化得到参数对象。并使用这些参数对象，在服务器端调用实际的方法。调用的返回值Java对象经过序列化之后，再发送回客户端。客户端再经过反序列化之后得到Java对象，返回给调用者。这中间的序列化过程对于使用者来说是透明的，由动态代理对象自动完成。除了序列化之外，RMI还使用了动态类加载技术。当需要进行反序列化的时候，如果该对象的类定义在当前JVM中没有找到，RMI会尝试从远端下载所需的类文件定义。可以在RMI程序启动的时候，通过JVM参数java.rmi.server.codebase来指定动态下载Java类文件的URL。

参考资料

• Java对象序列化规范
• RMI规范

Java深度解析之安全与对象序列化RMI，首发于润物无声。

Java反射与动态代理

以前文章中介绍Java注解的时候，多次提到了Java的反射API。与javax.lang.model不同的是，通过反射API可以获取程序在运行时刻的内部结构。反射API中提供的动态代理也是非常强大的功能，可以原生实现AOP中 的方法拦截功能。正如英文单词reflection的含义一样，使用反射API的时候就好像在看一个Java类在水中的倒影一样。知道了Java类的内部 结构之后，就可以与它进行交互，包括创建新的对象和调用对象中的方法等。这种交互方式与直接在源代码中使用的效果是相同的，但是又额外提供了运行时刻的灵活性。使用反射的一个最大的弊端是性能比较差。相同的操作，用反射API所需的时间大概比直接的使用要慢一两个数量级。不过现在的JVM实现中，反射操作的性能已经有了很大的提升。在灵活性与性能之间，总是需要进行权衡的。应用可以在适当的时机来使用反射API。

基本用法
Java 反射API的第一个主要作用是获取程序在运行时刻的内部结构。这对于程序的检查工具和调试器来说，是非常实用的功能。只需要短短的十几行代码，就可以遍历出来一个Java类的内部结构，包括其中的构造方法、声明的域和定义的方法等。这不得不说是一个很强大的能力。只要有了java.lang.Class类 的对象，就可以通过其中的方法来获取到该类中的构造方法、域和方法。对应的方法分别是getConstructor、getField和getMethod。这三个方法还有相应的getDeclaredXXX版本，区别在于getDeclaredXXX版本的方法只会获取该类自身所声明的元素，而不会考虑继承下来的。Constructor、Field和Method这三个类分别表示类中的构造方法、域和方法。这些类中的方法可以获取到所对应结构的元数据。

反射API的另外一个作用是在运行时刻对一个Java对象进行操作。 这些操作包括动态创建一个Java类的对象，获取某个域的值以及调用某个方法。在Java源代码中编写的对类和对象的操作，都可以在运行时刻通过反射API来实现。考虑下面一个简单的Java类。

class MyClass {
    public int count;
    public MyClass(int start) {
        count = start;
    }
    public void increase(int step) {
        count = count + step;
    }
}

使用一般做法和反射API都非常简单。

MyClass myClass = new MyClass(0); //一般做法
myClass.increase(2);
System.out.println("Normal -> " + myClass.count);
try {
    Constructor constructor = MyClass.class.getConstructor(int.class); //获取构造方法
    MyClass myClassReflect = constructor.newInstance(10); //创建对象
    Method method = MyClass.class.getMethod("increase", int.class);  //获取方法
    method.invoke(myClassReflect, 5); //调用方法
    Field field = MyClass.class.getField("count"); //获取域
    System.out.println("Reflect -> " + field.getInt(myClassReflect)); //获取域的值
} catch (Exception e) {
    e.printStackTrace();
}

由于数组的特殊性，Array类提供了一系列的静态方法用来创建数组和对数组中的元素进行访问和操作。

Object array = Array.newInstance(String.class, 10); //等价于 new String[10]
Array.set(array, 0, "Hello");  //等价于array[0] = "Hello"
Array.set(array, 1, "World");  //等价于array[1] = "World"
System.out.println(Array.get(array, 0));  //等价于array[0]

使用Java反射API的时候可以绕过Java默认的访问控制检查，比如可以直接获取到对象的私有域的值或是调用私有方法。只需要在获取到Constructor、Field和Method类的对象之后，调用setAccessible方法并设为true即可。有了这种机制，就可以很方便的在运行时刻获取到程序的内部状态。

处理泛型
Java 5中引入了泛型的概念之后，Java反射API也做了相应的修改，以提供对泛型的支持。由于类型擦除机制的存在，泛型类中的类型参数等信息，在运行时刻是不存在的。JVM看到的都是原始类型。对此，Java 5对Java类文件的格式做了修订，添加了Signature属性，用来包含不在JVM类型系统中的类型信息。比如以java.util.List接口为例，在其类文件中的Signature属性的声明是<E:Ljava/lang/Object;>Ljava/lang/Object;Ljava/util/Collection<TE;>;; ，这就说明List接口有一个类型参数E。在运行时刻，JVM会读取Signature属性的内容并提供给反射API来使用。

比如在代码中声明了一个域是List<String>类型的，虽然在运行时刻其类型会变成原始类型List，但是仍然可以通过反射来获取到所用的实际的类型参数。

Field field = Pair.class.getDeclaredField("myList"); //myList的类型是List
Type type = field.getGenericType();
if (type instanceof ParameterizedType) {
    ParameterizedType paramType = (ParameterizedType) type;
    Type[] actualTypes = paramType.getActualTypeArguments();
    for (Type aType : actualTypes) {
        if (aType instanceof Class) {
            Class clz = (Class) aType;
            System.out.println(clz.getName()); //输出java.lang.String
        }
    }
}

动态代理
熟悉设计模式的人对于代理模式可 能都不陌生。 代理对象和被代理对象一般实现相同的接口，调用者与代理对象进行交互。代理的存在对于调用者来说是透明的，调用者看到的只是接口。代理对象则可以封装一些内部的处理逻辑，如访问控制、远程通信、日志、缓存等。比如一个对象访问代理就可以在普通的访问机制之上添加缓存的支持。这种模式在RMI和EJB中都得到了广泛的使用。传统的代理模式的实现，需要在源代码中添加一些附加的类。这些类一般是手写或是通过工具来自动生成。JDK 5引入的动态代理机制，允许开发人员在运行时刻动态的创建出代理类及其对象。在运行时刻，可以动态创建出一个实现了多个接口的代理类。每个代理类的对象都会关联一个表示内部处理逻辑的InvocationHandler接 口的实现。当使用者调用了代理对象所代理的接口中的方法的时候，这个调用的信息会被传递给InvocationHandler的invoke方法。在 invoke方法的参数中可以获取到代理对象、方法对应的Method对象和调用的实际参数。invoke方法的返回值被返回给使用者。这种做法实际上相 当于对方法调用进行了拦截。熟悉AOP的人对这种使用模式应该不陌生。但是这种方式不需要依赖AspectJ等AOP框架。

下面的代码用来代理一个实现了List接口的对象。所实现的功能也非常简单，那就是禁止使用List接口中的add方法。如果在getList中传入一个实现List接口的对象，那么返回的实际就是一个代理对象，尝试在该对象上调用add方法就会抛出来异常。

public List getList(final List list) {
    return (List) Proxy.newProxyInstance(DummyProxy.class.getClassLoader(), new Class[] { List.class },
        new InvocationHandler() {
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                if ("add".equals(method.getName())) {
                    throw new UnsupportedOperationException();
                }
                else {
                    return method.invoke(list, args);
                }
            }
        });
 }

这里的实际流程是，当代理对象的add方法被调用的时候，InvocationHandler中的invoke方法会被调用。参数method就包含了调用的基本信息。因为方法名称是add，所以会抛出相关的异常。如果调用的是其它方法的话，则执行原来的逻辑。

使用案例
Java 反射API的存在，为Java语言添加了一定程度上的动态性，可以实现某些动态语言中的功能。比如在JavaScript的代码中，可以通过 obj["set" + propName]()来根据变量propName的值找到对应的方法进行调用。虽然在Java源代码中不能这么写，但是通过反射API同样可以实现类似 的功能。这对于处理某些遗留代码来说是有帮助的。比如所需要使用的类有多个版本，每个版本所提供的方法名称和参数不尽相同。而调用代码又必须与这些不同的版本都能协同工作，就可以通过反射API来依次检查实际的类中是否包含某个方法来选择性的调用。

Java 反射API实际上定义了一种相对于编译时刻而言更加松散的契约。如果被调用的Java对象中并不包含某个方法，而在调用者代码中进行引用的话，在编译时刻就会出现错误。而反射API则可以把这样的检查推迟到运行时刻来完成。通过把Java中的字节代码增强、类加载器和反射API结合起来，可以处理一些对灵 活性要求很高的场景。

在 有些情况下，可能会需要从远端加载一个Java类来执行。比如一个客户端Java程序可以通过网络从服务器端下载Java类来执行，从而可以实现自动更新 的机制。当代码逻辑需要更新的时候，只需要部署一个新的Java类到服务器端即可。一般的做法是通过自定义类加载器下载了类字节代码之后，定义出 Class类的对象，再通过newInstance方法就可以创建出实例了。不过这种做法要求客户端和服务器端都具有某个接口的定义，从服务器端下载的是 这个接口的实现。这样的话才能在客户端进行所需的类型转换，并通过接口来使用这个对象实例。如果希望客户端和服务器端采用更加松散的契约的话，使用反射API就可以了。两者之间的契约只需要在方法的名称和参数这个级别就足够了。服务器端Java类并不需要实现特定的接口，可以是一般的Java类。

动态代理的使用场景就更加广泛了。需要使用AOP中的方法拦截功能的地方都可以用到动态代理。Spring框架的AOP实现默认也使用动态代理。不过JDK中的动态代理只支持对接口的代理，不能对一个普通的Java类提供代理。不过这种实现在大部分的时候已经够用了。

参考资料

• Classworking toolkit: Reflecting  generics
• D?ecorating with dynamic proxies

Java I/O

在应用程序中，通常会涉及到两种类型的计算：CPU计算和I/O计算。对于大多数应用来说，花费在等待I/O上的时间是占较大比重的。通常需要等待速度较慢的磁盘或是网络连接完成I/O请求，才能继续后面的CPU计算任务。因此提高I/O操作的效率对应用的性能有较大的帮助。本文将介绍Java语言中与I/O操作相关的内容，包括基本的Java I/O和Java NIO，着重于基本概念和最佳实践。

流
Java语言提供了多个层次不同的概念来对I/O操作进行抽象。Java I/O中最早的概念是流，包括输入流和输出流，早在JDK 1.0中就存在了。简单的来说，流是一个连续的字节的序列。输入流是用来读取这个序列，而输出流则构建这个序列。InputStream和OutputStream所操纵的基本单元就是字节。每次读取和写入单个字节或是字节数组。如果从字节的层次来处理数据类型的话，操作会非常繁琐。可以用更易使用的流实现来包装基本的字节流。如果想读取或输出Java的基本数据类型，可以使用DataInputStream和DataOutputStream。它们所提供的类似readFloat和writeDouble这样的方法，会让处理基本数据类型变得很简单。如果希望读取或写入的是Java中的对象的话，可以使用ObjectInputStream和ObjectOutputStream。它们与对象的序列化机制一起，可以实现Java对象状态的持久化和数据传递。基本流所提供的对于输入和输出的控制比较弱。InputStream只提供了顺序读取、跳过部分字节和标记/重置的支持，而OutputStream则只能顺序输出。

流的使用
由于I/O操作所对应的实体在系统中都是有限的资源，需要妥善的进行管理。每个打开的流都需要被正确的关闭以释放资源。所遵循的原则是谁打开谁释放。如果一个流只在某个方法体内使用，则通过finally语句或是JDK 7中的try-with-resources语句来确保在方法返回之前，流被正确的关闭。如果一个方法只是作为流的使用者，就不需要考虑流的关闭问题。典型的情况是在servlet实现中并不需要关闭HttpServletResponse中的输出流。如果你的代码需要负责打开一个流，并且需要在不同的对象之间进行传递的话，可以考虑使用Execute Around Method模式。如下面的代码所示：

public void use(StreamUser user) {
    InputStream input = null;
    try {
        input = open();
        user.use(input);
    } catch(IOException e) {
        user.onError(e);
    } finally {
        if (input != null) {
            try {
                input.close();
            } catch (IOException e) {
                user.onError(e);
            }
        }
    }
 }

如上述代码中所看到的一样，由专门的类负责流的打开和关闭。流的使用者StreamUser并不需要关心资源释放的细节，只需要对流进行操作即可。

在使用输入流的过程中，经常会遇到需要复用一个输入流的情况，即多次读取一个输入流中的内容。比如通过URL.openConnection方法打开了一个远端站点连接的输入流，希望对其中的内容进行多次处理。这就需要把一个InputStream对象在多个对象中传递。为了保证每个使用流的对象都能获取到正确的内容，需要对流进行一定的处理。通常有两种解决的办法，一种是利用InputStream的标记支持。如果一个流支持标记的话（通过markSupported方法判断），就可以在流开始的地方通过mark方法添加一个标记，当完成一次对流的使用之后，通过reset方法就可以把流的读取位置重置到上次标记的位置，即流开始的地方。如此反复，就可以复用这个输入流。大部分输入流的实现是不支持标记的。可以通过BufferedInputStream进行包装来支持标记。

private InputStream prepareStream(InputStream ins) {
    BufferedInputStream buffered = new BufferedInputStream(ins);
    buffered.mark(Integer.MAX_VALUE);
    return buffered;
}
private void resetStream(InputStream ins) throws IOException {
    ins.reset();
    ins.mark(Integer.MAX_VALUE);
}

如上面的代码所示，通过prepareStream方法可以用一个BufferedInputStream来包装基本的InputStream。通过 mark方法在流开始的时候添加一个标记，允许读入Integer.MAX_VALUE个字节。每次流使用完成之后，通过resetStream方法重置即可。

另外一种做法是把输入流的内容转换成字节数组，进而转换成输入流的另外一个实现ByteArrayInputStream。这样做的好处是使用字节数组作为参数传递的格式要比输入流简单很多，可以不需要考虑资源相关的问题。另外也可以尽早的关闭原始的输入流，而无需等待所有使用流的操作完成。这两种做法的思路其实是相似的。BufferedInputStream在内部也创建了一个字节数组来保存从原始输入流中读入的内容。

private byte[] saveStream(InputStream input) throws IOException {
    ByteBuffer buffer = ByteBuffer.allocate(1024);
    ReadableByteChannel readChannel = Channels.newChannel(input);
    ByteArrayOutputStream output = new ByteArrayOutputStream(32 * 1024);
    WritableByteChannel writeChannel = Channels.newChannel(output);
    while ((readChannel.read(buffer)) > 0 || buffer.position() != 0) {
        buffer.flip();
        writeChannel.write(buffer);
        buffer.compact();
    }
    return output.toByteArray();
}

上面的代码中saveStream方法把一个InputStream保存为字节数组。

缓冲区
由于流背后的数据有可能比较大，在实际的操作中，通常会使用缓冲区来提高性能。传统的缓冲区的实现是使用数组来完成。比如经典的从InputStream到OutputStream的复制的实现，就是使用一个字节数组作为中间的缓冲区。NIO中引入的Buffer类及其子类，可以很方便的用来创建各种基本数据类型的缓冲区。相对于数组而言，Buffer类及其子类提供了更加丰富的方法来对其中的数据进行操作。后面会提到的通道也使用Buffer类进行数据传递。

在Buffer上进行的元素添加和删除操作，都围绕3个属性position、limit和capacity展开，分别表示Buffer当前的读写位置、可用的读写范围和容量限制。容量限制是在创建的时候指定的。Buffer提供的get/put方法都有相对和绝对两种形式。相对读写时的位置是相对于position的值，而绝对读写则需要指定起始的序号。在使用Buffer的常见错误就是在读写操作时没有考虑到这3个元素的值，因为大多数时候都是使用的是相对读写操作，而position的值可能早就发生了变化。一些应该注意的地方包括：将数据读入缓冲区之前，需要调用clear方法；将缓冲区中的数据输出之前，需要调用flip方法。

ByteBuffer buffer = ByteBuffer.allocate(32);
CharBuffer charBuffer = buffer.asCharBuffer();
String content = charBuffer.put("Hello ").put("World").flip().toString();
System.out.println(content);

上面的代码展示了Buffer子类的使用。首先可以在已有的ByteBuffer上面创建出其它数据类型的缓冲区视图，其次Buffer子类的很多方法是可以级联的，最后是要注意flip方法的使用。

字符与编码
在程序中，总是免不了与字符打交道，毕竟字符是用户直接可见的信息。而与字符处理直接相关的就是编码。相信不少人都曾经为了程序中的乱码问题而困扰。要弄清楚这个问题，就需要理解字符集和编码的概念。字符集，顾名思义，就是字符的集合。一个字符集中所包含的字符通常与地区和语言有关。字符集中的每个字符通常会有一个整数编码与其对应。常见的字符集有ASCII、ISO-8859-1和Unicode等。对于字符集中的每个字符，为了在计算机中表示，都需要转换某种字节的序列，即该字符的编码。同一个字符集可以有不同的编码方式。如果某种编码格式产生的字节序列，用另外一种编码格式来解码的话，就可能会得到错误的字符，从而产生乱码的情况。所以将一个字节序列转换成字符串的时候，需要知道正确的编码格式。

NIO中的java.nio.charset包提供了与字符集相关的类，可以用来进行编码和解码。其中的CharsetEncoder和CharsetDecoder允许对编码和解码过程进行精细的控制，如处理非法的输入以及字符集中无法识别的字符等。通过这两个类可以实现字符内容的过滤。比如应用程序在设计的时候就只支持某种字符集，如果用户输入了其它字符集中的内容，在界面显示的时候就是乱码。对于这种情况，可以在解码的时候忽略掉无法识别的内容。

String input = "你123好";
Charset charset = Charset.forName("ISO-8859-1");
CharsetEncoder encoder = charset.newEncoder();
encoder.onUnmappableCharacter(CodingErrorAction.IGNORE);
CharsetDecoder decoder = charset.newDecoder();
CharBuffer buffer = CharBuffer.allocate(32);
buffer.put(input);
buffer.flip();
try {
    ByteBuffer byteBuffer = encoder.encode(buffer);
    CharBuffer cbuf = decoder.decode(byteBuffer);
    System.out.println(cbuf);  //输出123
} catch (CharacterCodingException e) {
    e.printStackTrace();
}

上面的代码中，通过使用ISO-8859-1字符集的编码和解码器，就可以过滤掉字符串中不在此字符集中的字符。

Java I/O在处理字节流字之外，还提供了处理字符流的类，即Reader/Writer类及其子类，它们所操纵的基本单位是char类型。在字节和字符之间的桥梁就是编码格式。通过编码器来完成这两者之间的转换。在创建Reader/Writer子类实例的时候，总是应该使用两个参数的构造方法，即显式指定使用的字符集或编码解码器。如果不显式指定，使用的是JVM的默认字符集，有可能在其它平台上产生错误。

通道
通道作为NIO中的核心概念，在设计上比之前的流要好不少。通道相关的很多实现都是接口而不是抽象类。通道本身的抽象层次也更加合理。通道表示的是对支持I/O操作的实体的一个连接。一旦通道被打开之后，就可以执行读取和写入操作，而不需要像流那样由输入流或输出流来分别进行处理。与流相比，通道的操作使用的是Buffer而不是数组，使用更加方便灵活。通道的引入提升了I/O操作的灵活性和性能，主要体现在文件操作和网络操作上。

文件通道
对文件操作方面，文件通道FileChannel提供了与其它通道之间高效传输数据的能力，比传统的基于流和字节数组作为缓冲区的做法，要来得简单和快速。比如下面的把一个网页的内容保存到本地文件的实现。

FileOutputStream output = new FileOutputStream("baidu.txt");
FileChannel channel = output.getChannel();
URL url = new URL("http://www.baidu.com");
InputStream input = url.openStream();
ReadableByteChannel readChannel = Channels.newChannel(input);
channel.transferFrom(readChannel, 0, Integer.MAX_VALUE);

文件通道的另外一个功能是对文件的部分片段进行加锁。当在一个文件上的某个片段加上了排它锁之后，其它进程必须等待这个锁释放之后，才能访问该文件的这个片段。文件通道上的锁是由JVM所持有的，因此适合于与其它应用程序协同时使用。比如当多个应用程序共享某个配置文件的时候，如果Java程序需要更新此文件，则可以首先获取该文件上的一个排它锁，接着进行更新操作，再释放锁即可。这样可以保证文件更新过程中不会受到其它程序的影响。

另外一个在性能方面有很大提升的功能是内存映射文件的支持。通过FileChannel的map方法可以创建出一个MappedByteBuffer对象，对这个缓冲区的操作都会直接反映到文件内容上。这点尤其适合对大文件进行读写操作。

套接字通道
在套接字通道方面的改进是提供了对非阻塞I/O和多路复用I/O的支持。传统的流的I/O操作是阻塞式的。在进行I/O操作的时候，线程会处于阻塞状态等待操作完成。NIO中引入了非阻塞I/O的支持，不过只限于套接字I/O操作。所有继承自SelectableChannel的通道类都可以通过configureBlocking方法来设置是否采用非阻塞模式。在非阻塞模式下，程序可以在适当的时候查询是否有数据可供读取。一般是通过定期的轮询来实现的。

多路复用I/O是一种新的I/O编程模型。传统的套接字服务器的处理方式是对于每一个客户端套接字连接，都新创建一个线程来进行处理。创建线程是很耗时的操作，而有的实现会采用线程池。不过一个请求一个线程的处理模型并不是很理想。原因在于耗费时间创建的线程，在大部分时间可能处于等待的状态。而多路复用I/O的基本做法是由一个线程来管理多个套接字连接。该线程会负责根据连接的状态，来进行相应的处理。多路复用I/O依靠操作系统提供的select或相似系统调用的支持，选择那些已经就绪的套接字连接来处理。可以把多个非阻塞I/O通道注册在某个Selector上，并声明所感兴趣的操作类型。每次调用Selector的select方法，就可以选择到某些感兴趣的操作已经就绪的通道的集合，从而可以进行相应的处理。如果要执行的处理比较复杂，可以把处理转发给其它的线程来执行。

下面是一个简单的使用多路复用I/O的服务器实现。当有客户端连接上的时候，服务器会返回一个Hello World作为响应。

private static class IOWorker implements Runnable {
    public void run() {
        try {
            Selector selector = Selector.open();
            ServerSocketChannel channel = ServerSocketChannel.open();
            channel.configureBlocking(false);
            ServerSocket socket = channel.socket();
            socket.bind(new InetSocketAddress("localhost", 10800));
            channel.register(selector, channel.validOps());
            while (true) {
                selector.select();
                Iterator iterator = selector.selectedKeys().iterator();
                while (iterator.hasNext()) {
                    SelectionKey key = iterator.next();
                    iterator.remove();
                    if (!key.isValid()) {
                        continue;
                    }
                    if (key.isAcceptable()) {
                        ServerSocketChannel ssc = (ServerSocketChannel) key.channel();
                        SocketChannel sc = ssc.accept();
                        sc.configureBlocking(false);
                        sc.register(selector, sc.validOps());
                    }
                    if (key.isWritable()) {
                        SocketChannel client = (SocketChannel) key.channel();
                        Charset charset = Charset.forName("UTF-8");
                        CharsetEncoder encoder = charset.newEncoder();
                        CharBuffer charBuffer = CharBuffer.allocate(32);
                        charBuffer.put("Hello World");
                        charBuffer.flip();
                        ByteBuffer content = encoder.encode(charBuffer);
                        client.write(content);
                        key.cancel();
                    }
                }
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

上面的代码给出的只是非常简单的示例程序，只是展示了多路复用I/O的基本使用方式。在开发复杂网络应用程序的时候，使用一些Java NIO网络应用框架会让你事半功倍。目前来说最流行的两个框架是Apache MINA和Netty。在使用了Netty之后，Twitter的搜索功能速度提升达到了3倍之多。网络应用开发人员都可以使用这两个开源的优秀框架。

参考资料

• Java 6 I/O-related APIs & Developer Guides
• Top Ten New Things You Can Do with NIO
• Building Highly Scalable Servers with Java NIO

Java深度解析之反射机制动态代理与I/O，首发于润物无声。