【问题标题】:Java - weight of instantiationJava - 实例化的权重
【发布时间】:2012-02-27 05:35:18
【问题描述】:

假设我有一个非常轻量级的对象:

public class Point {
  public int x;
  public int y;
  public Point(int ax, int ay){
    x = ax;
    y = ay;
  }
}

而且我需要非常频繁地计算距离 - 例如,在移动设备上可能每秒触发几次的滚动事件期间。

如果每次都使用 new Point(a, b) 使代码更干净、更透明,性能是否足够显着,我应该考虑缓存一些引用并更新成员变量(而不是实例化)?

【问题讨论】:

    标签: java performance


    【解决方案1】:

    我个人不会担心每次你需要一个点时实例化这些对象。虽然是的,但缓存一些会快一点,但我同意它会使代码不那么干净。看看这本 Java 性能优化书对对象创建成本的看法:https://www.safaribooksonline.com/library/view/java-performance-tuning/0596000154/ch04.html

    基本上,如果旧的 Pentium II 每秒可以创建一百万个轻量级对象,那么考虑到当今更快的处理器/内存/等,我认为您不必担心。

    【讨论】:

    • +1 因为我认为我同意你的观点,但我认为我应该接受 Shiplu 的回答,因为第一句话真的总结了它。
    • 是的,Shiplu 总结得很好。不过不要低估可读性。鉴于这种情况下的性能差异可以忽略不计,我倾向于更简单、可读的解决方案。 (别担心,这不是偷懒!)
    • 是的,这是一个艰难的平衡。在这种情况下,一个投掷手势可能会非常快速地连续检查尺寸和位置,并且在没有大型处理器保证的手持设备上,我推迟了两个点的性能,但通常我更喜欢“漂亮”的代码而不是挤压每个每条线路的最后一滴电源。感谢您的回复。
    • 好点,我没有关注这个问题的移动方面。在资源有限的情况下,任何简单的优化都不会受到伤害!
    【解决方案2】:

    您可能还希望阅读以下资源,它总结了现代 JVM 中分配的性能成本以及使用与您的对象重用方案有许多相似之处的对象池的影响正在考虑。

    http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html

    应考虑可能的 JVM 优化,例如下面引用的那些。

    JIT 编译器可以执行额外的优化,将对象分配的成本降低到零。

    但是,我并不特别熟悉当今移动设备中使用的 JVM 实现,它们很可能无法与普通计算机上使用的实现相提并论。

    在任何一种情况下,如果可能的话,通常不建议执行过早的优化,除非有明显的和需要的性能提升。

    总而言之,除非您测量到 Point 对象的分配成本占用了太多时间,否则您不应该牺牲代码质量来进一步改进它。

    【讨论】:

      【解决方案3】:

      更新前一个实例不会分配新内存,但创建新实例会。 jvm 垃圾收集器有时会释放内存。你无法控制它。因此,除非您保留历史记录,否则最好更新现有实例。

      但是,您始终可以使用 setter 函数。

      public class Point {
        public int x;
        public int y;
        public Point(int ax, int ay){
         this.setXY(ax, ay);
        }
        public void setXY(int ax, int ay){]
          x = ax;
          y = ay;
        }
      }
      

      【讨论】:

      • 谢谢。我已经知道了,但是在简短而简洁的答案中看到粗体字让我意识到我只是懒惰
      • 使对象可变(通过提供setter)并不总是更好,事实上,使用不可变对象有很多好处,这些好处可能远远超过对象创建成本。请参阅此处了解一些注意事项:stackoverflow.com/a/3511336/372860
      【解决方案4】:

      您可以使用一些实例变量,而不是在每次调用时构造对象。 这会影响您的性能,因为这样您必须每次都创建和初始化对象。

      所以最好有一个更新实例变量的方法调用。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-06-10
        • 1970-01-01
        • 2018-06-13
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多