看高手代码--从小case学大道理

今天看sun的HttpMessages.java文件，虽然文件很小，但是对我的启发很大。
前面定义了大量的HTTP常量：

    ...
    ...
    private static final String STATUS_305 = "Use Proxy";
    private static final String STATUS_307 = "Temporary Redirect";
    private static final String STATUS_400 = "Bad Request";
    private static final String STATUS_401 = "Unauthorized";
    private static final String STATUS_402 = "Payment Required";
    private static final String STATUS_403 = "Forbidden";
    private static final String STATUS_404 = "Not Found";
    private static final String STATUS_405 = "Method Not Allowed";
    private static final String STATUS_406 = "Not Acceptable";
    private static final String STATUS_407 = "Proxy Authentication Required";
    private static final String STATUS_408 = "Request Timeout";
    ...
    ...

也可以趁机从这里查看HTTP返回值的意义^_^。然后定义了一个java.util.concurrent.ConcurrentHashMap的变量httpStatusCodeMappings，再往里面添加刚才定义的常量（这个操作放在了一个静态块里），如：

static {
        httpStatusCodeMappings.put("sc.100", STATUS_100);
        httpStatusCodeMappings.put("sc.101", STATUS_101);
        httpStatusCodeMappings.put("sc.200", STATUS_200);
        httpStatusCodeMappings.put("sc.201", STATUS_201);
        httpStatusCodeMappings.put("sc.202", STATUS_202);
        httpStatusCodeMappings.put("sc.203", STATUS_203);
  ...
  ...

最重要的就是这个方法了，先看代码：

public static String getMessage(int status) {

        // Return the status message for the most frequently used status
        // codes directly, without any lookup
        switch (status) {
            case 200: return STATUS_200;
            case 302: return STATUS_302;
            case 400: return STATUS_400;
            case 404: return STATUS_404;
	}

        return httpStatusCodeMappings.get("sc."+ status);
    }

这段代码的用途很简单，就是要返回状态码对应的Message，而这些这些消息都已经存放在httpStatusCodeMappings变量里了，为了提高访问常用的几个返回码的Message，它直接用了一个静态块，而不去lookup那个map了，这就是高手！

评论

56 楼 love_ai87 2010-06-01  

应该是先搞定，再优化么，哪能一开始就想到怎么去优化的

55 楼 lgdlgd 2010-06-01  

如果代码真是这样的，那反而是很不注意小节啊,已经在CASE中过滤掉的那几个不应该再放到MAP中增加MAP的长度啊。

54 楼 chandler 2010-06-01  

我觉得。性能问题怎么说呢。满足用户需求的情况下，可以忽视性能。比方说一个操作。用户需要10秒钟。如果你跑了1分钟，那么肯定要优化。web也要。但是你跑了9秒了。代码好看点比那个性能要重要的多。你1秒跑完的。那么可以无视性能的了。
   其实这里没什么好争的。jdk中的要求性能比一般我们做的应用要求要高的多。以jdk的性能要求来要求应用的java代码，有点过分。
   PS。本人不觉得这段代码很难读。

53 楼 mtnt2008 2010-06-01  

呵呵，效率是提高了，不错

52 楼 kuaileqingfeng 2010-06-01  

以前一直认为Map的查询效率是O(1)的，没必要用这种方式返回状态码，我不知道case语句的效率会更高，看了各位的讨论，获益良多。

51 楼 blastblend 2010-06-01  

承认这种做法的价值是必要的。
这就好比，有人说国内不是造战斗机的地方，那么好吧，这个我们可以不管不在乎，我们专注于业务，致力于各行各业的信息化；米国人不这么想，他们要造战斗机来统治世界，所以他们这么做了，造出jdk和各种先进的战斗机。

50 楼 jxausea 2010-06-01  

sw1982 写道

...lookup 一下hashmap真的那么低效吗？ 建议复习下数据结构哦，你这些总结是没错，可是很表面

看来你没有认真阅读

49 楼 langyu 2010-06-01  

抛出异常的爱 写道

langyu 写道

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。

欢乐

是挺欢乐的
计算机机上书的那个数量级，至少会让我建立起对内存/磁盘/网络缓存模型的感性概念，避免在代码中犯幼稚的错误。到具体应该中，是得评估是否需要优化及优化的质量。
之前做过的web项目就有响应时间的大概要求，在写好代码后，边重构边测试性能瓶颈点，加以简单的优化，这没什么不对吧。不同的应用有不同的需求，况且楼主所说的还得需要提供大量服务，几行代码就能搞定的优化，有必要陷入到与程序员及项目时间的讨论吗。
在讨论问题时，有没有意见都可以指出来。都是做技术的，对那个数量值有意见，那我回去再查下，可能我也记错了。而不是抛出两个字，表明你不屑的态度。

48 楼 抛出异常的爱 2010-06-01  

mathfox 写道

抛出异常的爱 写道

langyu 写道

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。

欢乐

你的评论怎么改了。

抛哥，看看我下面的言论有什么不当的，

每秒事务的个数
用来作性能测试
如果没有测试目标
那个值是没用的.
当然如果有了测试目标
还要确定主要修正范围
作这个范围的review
确定需要修正点.
并给出假想方案的性能提高可能值
(一般这时会写demo.否则谁能凭空猜出这东西能快几毫秒)
最后如果被审批下来
(80%是不能被审批.....再找方案)
痛苦才刚刚开始

47 楼 alswl 2010-06-01  

的确，不管怎样，这样的设计方法是值得学习的

46 楼 mathfox 2010-06-01  

抛出异常的爱 写道

langyu 写道

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。

欢乐

你的评论怎么改了。

抛哥，看看我下面的言论有什么不当的，

45 楼 mathfox 2010-06-01  

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

请问你是怎么对比的。

顺序读硬盘是100多M/S吧。
内存是nG/s吧？

这有个数量级对比了吧。

具体怎么算，oracle trouble shooting是里面有个计算公式。我没记住。

请问你是怎么算的？

44 楼 抛出异常的爱 2010-06-01  

langyu 写道

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。

欢乐

43 楼 langyu 2010-06-01  

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。

42 楼 抛出异常的爱 2010-06-01  

sw1982 写道

我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。

你面试的人在项目中是需要去作优化还是叶公好龙?
对一个以前只作业务开发的人来说不优化才是好程序员
如果你认为程序员时间比分布服务器价格更贱的话....
我也没有办法.

41 楼 archerfrank 2010-06-01  

sw1982 写道

做业务和玩编程不是一个概念。如果你觉得计算几个hash也是性能浪费，真不如去汇编得了。

你可以尝试量化一下， 而且架构师通常会建议“先抗住再优化”，而《重构》这本书自身都建议，不到万不得已，不要优化代码的技巧！

skydream 写道

sw1982 写道

...lookup 一下hashmap真的那么低效吗？ 建议复习下数据结构哦，你这些总结是没错，可是很表面

典型的没有写过高并发程序的思维方式，明明可以节约的地方，仅仅几行代码就可以优化，偏偏不做。

hashmap再快，也比case 一个 整型满上1w倍。

性能，是一点一点挤牙膏挤出来的，哪能到处浪费啊。

好像还说遇到switch case 就是bad smell。是可以重构的地方。。
建议使用strategy或者state pattern 替换之。

40 楼 swanky_yao 2010-06-01  

langyu 写道

突然想到一个现实中的已使用场景，JDK里面的

Integer类在初始化时会缓存-128---127之间所有整数的Integer实例，就是认为这种一个字节的常用整数会非常容易出现。之后对这个范围整数创建Integer对象时都是从cache中取。

就会出现这种情况
Integer i = 300;
Integer j = 300;
System.out.println(i == j);//false，the different reference

Integer i = 30;
Integer j = 30;
System.out.println(i == j);//true, the same reference

The funny world!

貌似面试也经常碰到这样的考题....

39 楼 langyu 2010-06-01  

突然想到一个现实中的已使用场景，JDK里面的

Integer类在初始化时会缓存-128---127之间所有整数的Integer实例，就是认为这种一个字节的常用整数会非常容易出现。之后对这个范围整数创建Integer对象时都是从cache中取。

就会出现这种情况
Integer i = 300;
Integer j = 300;
System.out.println(i == j);//false，the different reference

Integer i = 30;
Integer j = 30;
System.out.println(i == j);//true, the same reference

The funny world!

38 楼 coffeesweet 2010-06-01  

我不会，学习了

37 楼 hardPass 2010-06-01  

我和楼主一样，很久之前看到上面的代码也有惊叹的感觉。

后来做系统的时候，也用了类似的方法，分级做cache——
命中率最高的内容放在最快的cache里。

这种细节，也许对于公司的项目真没什么帮助，但是自己写自己的代码时候，就是需要慢慢研磨的。