【问题标题】:Java: Should I construct lightweight objects each time or cache instance?Java:我应该每次都构造轻量级对象还是缓存实例?
【发布时间】:2014-05-14 15:52:49
【问题描述】:

在代码审查期间,我的一位同事查看了这段代码:

public List<Item> extractItems(List<Object[]> results) { 
    return Lists.transform(results, new Function<Object[], Item>() {
        @Override
        public Item apply(Object[] values) {
            ...
        }
    });
}

他建议改成这样:

public List<Item> extractItems(List<Object[]> results) { 
    return Lists.transform(results, getTransformer());
}

private Function<Object[], Item> transformer;

private Function<Object[], Item> getTransformer() {
    if(transformer == null) {
        transformer = new Function<Object[], Item>() {
            @Override
            public Item apply(Object[] values) {
                ...
             }
        };
    }
    return transformer;
 }

因此,我们正在考虑采用 new Function() 构造,并将其移至成员变量并在下次重新使用。

虽然我理解他的逻辑和推理,但我想我并不认为我应该为我创建的每个可能的遵循这种模式的对象执行此操作。似乎有一些很好的理由不这样做,但我不确定。

你的想法是什么?我们应该总是缓存这样重复创建的对象吗?

更新

Function 是 google guava 的东西,没有状态。有几个人指出了这种变化的非线程安全方面,这是完全有效的,但实际上并不是一个问题。我更多的是问构造vs缓存小对象的做法,哪个更好?

【问题讨论】:

  • 这里的问题似乎很主观,最好放在Code Review Exchange
  • 谢谢,我不知道那个交流。

标签: java performance object caching memory


【解决方案1】:

您同事的提议不是线程安全的。它还散发着过早优化的味道。 Function 对象的构造是否是已知(经过测试)的 CPU 瓶颈?如果没有,就没有理由这样做。这不是内存问题 - 您没有保留引用,因此 GC 会将其清除,可能来自 Eden。

【讨论】:

  • 正是我要说的。 +1 用于线程安全。现在使用起来稍微快了一点,但安全性大大降低了!
  • new Function() 是 google guava 的东西,并且没有状态,所以即使两个线程创建了两个对象,并且只有第二个被卡住,我们也不在乎。我几乎提出了“忽略更改的非线程安全方面”的问题,但是您的观点肯定是有效的(我看到了同样的事情)。我的问题更针对“所有条件相同,是否最好保存实例而不是每次都重新创建它们”。
  • @SeanAdkinson 我坚持过早优化。您正在以更少的 CPU 使用率换取更多的内存使用率,但不知道其中任何一项是否重要。
【解决方案2】:

如前所述,这都是过早的优化。收益可能无法衡量,应该忘记整个故事。

但是,transformer 是无状态的,出于可读性的原因,我会选择它。匿名函数作为参数会污染代码。

只需放弃延迟初始化 - 无论何时使用该类,您都会使用 transformer,对吧? (*) 所以把它放在static final 字段中,也许你可以在其他地方重复使用它。


(*) 即使没有,在整个应用程序生命周期内创建和持有一个 便宜 对象也没关系。

【讨论】:

    猜你喜欢
    • 2014-10-01
    • 2011-01-11
    • 2010-09-18
    • 2010-12-31
    • 2017-10-30
    • 1970-01-01
    • 2017-12-22
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多