zoukankan      html  css  js  c++  java
  • IntegerCache的一些联想

    【简述】
      Jdk1.5中引入了Integer对象的cache机制。最初是因为一道面试题踩了坑,后来仔细看了Integer类才知道这个IntegerCache。

      这段代码并不难理解,其它的包装类也同时引入了缓存机制,最触动我的地方在于,优秀的框架和源码都在不断地从实践中追求性能和极致,我们应该用怎样的态度对待我们手里的代码呢?
    【分析】
      按照正常的思维,需要装箱时这里直接new一个对象就好。但这里给定了一个默认范围,[-128,127]内的数字进行装箱时首先回去IntegerCache维护的一个cache[]中获取,没有的话再new一个。这样的好处在于如果有高频的转换,这里的缓存将会节省可观的内存,并加快响应速度。在Integer.valueOf(int i)方法的注释中对此说明:该方法为了更好地性能缓存了频繁使用的值(frequently requested values)。这里引起我兴趣的是这个默认范围的设定[-128,127]
    在IntegerCache类的注释中,有写到:Cache to support the object identity semantics of autoboxing for values between -128 and 127 (inclusive) as required by JLS.
    这里查阅了资料,最终的结论是:
      1.JSL中约定的是-128到127,这是至少要缓存的范围。可以缓存更大的范围,但是[-128,127]是必须的。理想情况下,给定的数值所产生的引用应该总是相同的,但实际上不可能办到。所以设计者给定一个范围,要求至少在[-128,127]是必须要缓存的。
      2.这个范围,可以覆盖大多数常见的情况(most common cases),保证相同数值对应相同的引用,而不会施加不当的性能损失,尤其是在小型设备,节约出来的内存将是非常有用的。


    【启发】
      这段代码其实在当时给了我很大的启发。之前所认为的代码优化,总是会去想一些高大上的技术,但是具体怎么落实并没有思路。但是这段代码带给我的启发是,只要是着力点找到了,用一些简单的手法我们也能有效提升代码的性能,以至于后来的开发工作中,如果某些对象使用很高频,会有意识去维护一个数组,或者集合提升对象的复用,我觉得这也算是看代码带来的一些处理思路上的改进。

  • 相关阅读:
    Flink集群模式部署及案例执行
    Solr查询解析及内核剖析
    Spark Streaming流计算核心概念
    Kaldi语音识别CVTE模型实战
    Kaldi基础代码库及建模
    Kaldi样例实战
    Solr文本分析剖析【文本分析、分词器详解、自定义文本分析字段及分词器】
    Flink场景分析与比较【事件驱动、数据分析、数据管道】
    什么是Apache Flink实时流计算框架?
    基于Tesseract实现图片文字识别
  • 原文地址:https://www.cnblogs.com/bruceChan0018/p/15248997.html
Copyright © 2011-2022 走看看