Effective Java 71 Use lazy initialization judiciously
2014-05-08 08:25
471 查看
Lazy initialization - It decreases the cost of initializing a class or creating an instance, at the expense of increasing the cost of accessing the lazily initialized field. Depending on what fraction of lazily initialized fields eventually require initialization,
how expensive it is to initialize them, and how often each field is accessed, lazy initialization can (like many "optimizations") actually harm performance.
The only way to know for sure is to measure the performance of the class with and without lazy initialization.
Principle
Normal initialization of an instance field - Under most circumstances, normal initialization is preferable to lazy initialization.
// Normal initialization of an instance field
private final FieldType field = computeFieldValue();
synchronized accessor - If you use lazy initialization to break an initialization circularity, use a synchronized accessor, as it is the simplest, clearest alternative:
// Lazy initialization of instance field - synchronized accessor
private FieldType field;
synchronized FieldType getField() {
if (field == null)
field = computeFieldValue();
return field;
}
Both of these idioms (normal initialization and lazy initialization with a synchronized accessor ) are unchanged when applied to static fields, except that you add the static modifier to the field and accessor declarations.
lazy initialization holder class idiom - If you need to use lazy initialization for performance on a static field, use the lazy initialization holder class idiom .
// Lazy initialization holder class idiom for static fields
private static class FieldHolder {
static final FieldType field = computeFieldValue();
}
static FieldType getField() { return FieldHolder.field; }
Double-check idiom - If you need to use lazy initialization for performance on an instance field, use the double-check idiom.
// Double-check idiom for lazy initialization of instance fields
private volatile FieldType field;
FieldType getField() {
FieldType result = field;
if (result == null) { // First check (no locking)
synchronized(this) {
result = field;
if (result == null) // Second check (with locking)
field = result = computeFieldValue();
}
}
return result;
}
Single-check idiom - Occasionally, you may need to lazily initialize an instance field that can tolerate repeated initialization.
// Single-check idiom - can cause repeated initialization!
private volatile FieldType field;
private FieldType getField() {
FieldType result = field;
if (result == null)
field = result = computeFieldValue();
return result;
}
Note
When the double- check or single-check idiom is applied to a numerical primitive field, the field's value is checked against 0 (the default value for numerical primitive variables) rather than null.
Racy single-check idiom - If you don't care whether every thread recalculates the value of a field, and the type of the field is a primitive other than long or double , then you may choose to remove the volatile modifier from the field declaration in the
single-check idiom(e.g. String instances to cache their hash codes).
// racy single-check idiom - can cause repeated initialization!
private FieldType field;
private FieldType getField() {
FieldType result = field;
if (result == null)
field = result = computeFieldValue();
return result;
}
Summary
You should initialize most fields normally, not lazily. If you must initialize a field lazily in order to achieve your performance goals, or to break a harmful initialization circularity, then use the appropriate lazy initialization technique. For instance
fields, it is the double-check idiom; for static fields, the lazy initialization holder class idiom. For instance fields that can tolerate repeated initialization, you may also consider the single-check idiom.
how expensive it is to initialize them, and how often each field is accessed, lazy initialization can (like many "optimizations") actually harm performance.
The only way to know for sure is to measure the performance of the class with and without lazy initialization.
Principle
Normal initialization of an instance field - Under most circumstances, normal initialization is preferable to lazy initialization.
// Normal initialization of an instance field
private final FieldType field = computeFieldValue();
synchronized accessor - If you use lazy initialization to break an initialization circularity, use a synchronized accessor, as it is the simplest, clearest alternative:
// Lazy initialization of instance field - synchronized accessor
private FieldType field;
synchronized FieldType getField() {
if (field == null)
field = computeFieldValue();
return field;
}
Both of these idioms (normal initialization and lazy initialization with a synchronized accessor ) are unchanged when applied to static fields, except that you add the static modifier to the field and accessor declarations.
lazy initialization holder class idiom - If you need to use lazy initialization for performance on a static field, use the lazy initialization holder class idiom .
// Lazy initialization holder class idiom for static fields
private static class FieldHolder {
static final FieldType field = computeFieldValue();
}
static FieldType getField() { return FieldHolder.field; }
Double-check idiom - If you need to use lazy initialization for performance on an instance field, use the double-check idiom.
// Double-check idiom for lazy initialization of instance fields
private volatile FieldType field;
FieldType getField() {
FieldType result = field;
if (result == null) { // First check (no locking)
synchronized(this) {
result = field;
if (result == null) // Second check (with locking)
field = result = computeFieldValue();
}
}
return result;
}
Single-check idiom - Occasionally, you may need to lazily initialize an instance field that can tolerate repeated initialization.
// Single-check idiom - can cause repeated initialization!
private volatile FieldType field;
private FieldType getField() {
FieldType result = field;
if (result == null)
field = result = computeFieldValue();
return result;
}
Note
When the double- check or single-check idiom is applied to a numerical primitive field, the field's value is checked against 0 (the default value for numerical primitive variables) rather than null.
Racy single-check idiom - If you don't care whether every thread recalculates the value of a field, and the type of the field is a primitive other than long or double , then you may choose to remove the volatile modifier from the field declaration in the
single-check idiom(e.g. String instances to cache their hash codes).
// racy single-check idiom - can cause repeated initialization!
private FieldType field;
private FieldType getField() {
FieldType result = field;
if (result == null)
field = result = computeFieldValue();
return result;
}
Summary
You should initialize most fields normally, not lazily. If you must initialize a field lazily in order to achieve your performance goals, or to break a harmful initialization circularity, then use the appropriate lazy initialization technique. For instance
fields, it is the double-check idiom; for static fields, the lazy initialization holder class idiom. For instance fields that can tolerate repeated initialization, you may also consider the single-check idiom.
相关文章推荐
- MVC4中视图获取控制器中返回的json格式数据
- html入门 总结
- C Ch5重點整理-Array
- MIT differential equation---5
- Jquery操作select小结
- MAC OS 下配置NODEJS 开发环境及调试
- css设置各种中文字体,雅黑,黑体,宋体,楷体等等
- <?php echo "<script language=javascript>alert('".$var['id']."!');</script>"; ?>
- json 解析 真是一篇让我泪流满面的好文章
- 关于html页面上的DOCTYPE
- JavaScript中读取和保存文件实例
- 在JavaScript中使用timer示例
- javascript中setTimeout的问题解决方法
- js冒泡、捕获事件及阻止冒泡方法详细总结
- jquery查找tr td 示例模拟
- js动态删除div元素基本思路及实现代码
- JavaScript怎么判断图片是否加载完成以便获取其尺寸
- javascript与有限状态机详解
- Javascript单元测试框架QUnitjs详细介绍
- jquery的ajax跨域请求原理和示例