Tại sao sau đây làm việc tốt?
String str;
while (condition) {
str = calculateStr();
.....
}Nhưng điều này được cho là nguy hiểm / không chính xác:
while (condition) {
String str = calculateStr();
.....
}Có cần phải khai báo các biến ngoài vòng lặp không?
Câu trả lời:
Trong ví dụ của bạn tôi đoán strlà không sử dụng bên ngoài của whilevòng lặp, nếu không bạn sẽ không được đặt câu hỏi, vì tuyên bố nó bên trong whilevòng lặp sẽ không là một lựa chọn, vì nó sẽ không biên dịch.
Vì vậy, kể từ khi strđược không sử dụng bên ngoài vòng lặp, phạm vi nhỏ nhất có thể cho strlà trong các vòng lặp while.
Vì vậy, câu trả lời rõ ràng là strhoàn toàn nên được khai báo trong vòng lặp while. Không ifs, không ands, không buts.
Trường hợp duy nhất mà quy tắc này có thể bị vi phạm là nếu vì một lý do nào đó, điều quan trọng quan trọng là mọi chu kỳ đồng hồ phải được vắt ra khỏi mã, trong trường hợp đó bạn có thể muốn xem xét việc khởi tạo một cái gì đó trong phạm vi bên ngoài và sử dụng lại thay vì tái hiện nó trên mỗi lần lặp của một phạm vi bên trong. Tuy nhiên, điều này không áp dụng cho ví dụ của bạn, do tính bất biến của các chuỗi trong java: một thể hiện mới của str sẽ luôn được tạo ở đầu vòng lặp của bạn và nó sẽ phải bị loại bỏ ở cuối vòng lặp, vì vậy sẽ có không có khả năng để tối ưu hóa ở đó.
EDIT: (đưa ra nhận xét của tôi dưới đây trong câu trả lời)
Trong mọi trường hợp, cách đúng đắn để làm mọi thứ là viết đúng mã của bạn, thiết lập yêu cầu hiệu suất cho sản phẩm của bạn, đo sản phẩm cuối cùng của bạn theo yêu cầu này và nếu nó không thỏa mãn nó, thì hãy tối ưu hóa mọi thứ. Và điều thường xảy ra là bạn tìm cách cung cấp một số tối ưu hóa thuật toán chính thức và tốt đẹp chỉ trong một vài nơi khiến chương trình của chúng tôi đáp ứng các yêu cầu về hiệu suất của nó thay vì phải đi khắp toàn bộ cơ sở mã của bạn và điều chỉnh và hack mọi thứ trong đó để bóp chu kỳ đồng hồ ở đây và ở đó.
Tôi đã so sánh mã byte của hai ví dụ (tương tự) đó:
Hãy xem 1. ví dụ :
package inside;
public class Test {
public static void main(String[] args) {
while(true){
String str = String.valueOf(System.currentTimeMillis());
System.out.println(str);
}
}
}sau đó javac Test.java, javap -c Testbạn sẽ nhận được:
public class inside.Test extends java.lang.Object{
public inside.Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: invokestatic #2; //Method java/lang/System.currentTimeMillis:()J
3: invokestatic #3; //Method java/lang/String.valueOf:(J)Ljava/lang/String;
6: astore_1
7: getstatic #4; //Field java/lang/System.out:Ljava/io/PrintStream;
10: aload_1
11: invokevirtual #5; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
14: goto 0
}Hãy xem 2. ví dụ :
package outside;
public class Test {
public static void main(String[] args) {
String str;
while(true){
str = String.valueOf(System.currentTimeMillis());
System.out.println(str);
}
}
}sau đó javac Test.java, javap -c Testbạn sẽ nhận được:
public class outside.Test extends java.lang.Object{
public outside.Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: invokestatic #2; //Method java/lang/System.currentTimeMillis:()J
3: invokestatic #3; //Method java/lang/String.valueOf:(J)Ljava/lang/String;
6: astore_1
7: getstatic #4; //Field java/lang/System.out:Ljava/io/PrintStream;
10: aload_1
11: invokevirtual #5; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
14: goto 0
}Các quan sát cho thấy rằng không có sự khác biệt giữa hai ví dụ này. Đó là kết quả của thông số kỹ thuật JVM ...
Nhưng trong tên của thực hành mã hóa tốt nhất, nên khai báo biến trong phạm vi nhỏ nhất có thể (trong ví dụ này là bên trong vòng lặp, vì đây là nơi duy nhất sử dụng biến).
finalyêu thích: khai báo strnhư finaltrong insidetrường hợp gói cũng không có gì khác biệt =)
Khai báo các đối tượng trong phạm vi nhỏ nhất cải thiện khả năng đọc .
Hiệu suất không thành vấn đề đối với các trình biên dịch ngày nay. (Trong kịch bản này)
Từ góc độ bảo trì, tùy chọn thứ 2 là tốt hơn.
Khai báo và khởi tạo các biến ở cùng một vị trí, trong phạm vi hẹp nhất có thể.
Như Donald Ervin Knuth đã nói:
"Chúng ta nên quên đi những hiệu quả nhỏ, nói về 97% thời gian: tối ưu hóa sớm là gốc rễ của mọi tội lỗi"
tức là) tình huống trong đó một lập trình viên cho phép xem xét hiệu suất ảnh hưởng đến việc thiết kế một đoạn mã. Điều này có thể dẫn đến một thiết kế không sạch như nó có thể hoặc mã không chính xác, bởi vì mã phức tạp bởi tối ưu hóa và lập trình viên bị phân tâm khi tối ưu hóa .
Hãy bỏ qua câu trả lời cập nhật ...
Đối với những người quan tâm đến hiệu suất, hãy loại bỏ System.out và giới hạn vòng lặp ở mức 1 byte. Sử dụng gấp đôi (kiểm tra 1/2) và sử dụng Chuỗi (3/4) thời gian đã trôi qua tính bằng mili giây được đưa ra dưới đây với Windows 7 Professional 64 bit và JDK-1.7.0_21. Các mã byte (cũng được đưa ra dưới đây cho test1 và test2) không giống nhau. Tôi đã quá lười biếng để kiểm tra với các đối tượng có thể thay đổi và tương đối phức tạp.
gấp đôi
Test1 mất: 2710 ms
Test2 lấy: 2790 ms
Chuỗi (chỉ cần thay thế gấp đôi bằng chuỗi trong các bài kiểm tra)
Test3 mất: 1200 ms
Test4 mất: 3000 ms
Biên dịch và nhận mã byte
javac.exe LocalTest1.java
javap.exe -c LocalTest1 > LocalTest1.bc
public class LocalTest1 {
public static void main(String[] args) throws Exception {
long start = System.currentTimeMillis();
double test;
for (double i = 0; i < 1000000000; i++) {
test = i;
}
long finish = System.currentTimeMillis();
System.out.println("Test1 Took: " + (finish - start) + " msecs");
}
}
public class LocalTest2 {
public static void main(String[] args) throws Exception {
long start = System.currentTimeMillis();
for (double i = 0; i < 1000000000; i++) {
double test = i;
}
long finish = System.currentTimeMillis();
System.out.println("Test1 Took: " + (finish - start) + " msecs");
}
}
Compiled from "LocalTest1.java"
public class LocalTest1 {
public LocalTest1();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]) throws java.lang.Exception;
Code:
0: invokestatic #2 // Method java/lang/System.currentTimeMillis:()J
3: lstore_1
4: dconst_0
5: dstore 5
7: dload 5
9: ldc2_w #3 // double 1.0E9d
12: dcmpg
13: ifge 28
16: dload 5
18: dstore_3
19: dload 5
21: dconst_1
22: dadd
23: dstore 5
25: goto 7
28: invokestatic #2 // Method java/lang/System.currentTimeMillis:()J
31: lstore 5
33: getstatic #5 // Field java/lang/System.out:Ljava/io/PrintStream;
36: new #6 // class java/lang/StringBuilder
39: dup
40: invokespecial #7 // Method java/lang/StringBuilder."<init>":()V
43: ldc #8 // String Test1 Took:
45: invokevirtual #9 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
48: lload 5
50: lload_1
51: lsub
52: invokevirtual #10 // Method java/lang/StringBuilder.append:(J)Ljava/lang/StringBuilder;
55: ldc #11 // String msecs
57: invokevirtual #9 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
60: invokevirtual #12 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
63: invokevirtual #13 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
66: return
}
Compiled from "LocalTest2.java"
public class LocalTest2 {
public LocalTest2();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]) throws java.lang.Exception;
Code:
0: invokestatic #2 // Method java/lang/System.currentTimeMillis:()J
3: lstore_1
4: dconst_0
5: dstore_3
6: dload_3
7: ldc2_w #3 // double 1.0E9d
10: dcmpg
11: ifge 24
14: dload_3
15: dstore 5
17: dload_3
18: dconst_1
19: dadd
20: dstore_3
21: goto 6
24: invokestatic #2 // Method java/lang/System.currentTimeMillis:()J
27: lstore_3
28: getstatic #5 // Field java/lang/System.out:Ljava/io/PrintStream;
31: new #6 // class java/lang/StringBuilder
34: dup
35: invokespecial #7 // Method java/lang/StringBuilder."<init>":()V
38: ldc #8 // String Test1 Took:
40: invokevirtual #9 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
43: lload_3
44: lload_1
45: lsub
46: invokevirtual #10 // Method java/lang/StringBuilder.append:(J)Ljava/lang/StringBuilder;
49: ldc #11 // String msecs
51: invokevirtual #9 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
54: invokevirtual #12 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
57: invokevirtual #13 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
60: return
}Thật sự không dễ để so sánh hiệu năng với tất cả các tối ưu hóa JVM. Tuy nhiên, nó là một phần có thể. Thử nghiệm tốt hơn và kết quả chi tiết trong Google Caliper
Điều này không giống với mã ở trên. Nếu bạn chỉ mã hóa một vòng lặp giả JVM sẽ bỏ qua nó, vì vậy ít nhất bạn cần gán và trả về một cái gì đó. Điều này cũng được khuyến nghị trong tài liệu Caliper.
@Param int size; // Set automatically by framework, provided in the Main
/**
* Variable is declared inside the loop.
*
* @param reps
* @return
*/
public double timeDeclaredInside(int reps) {
/* Dummy variable needed to workaround smart JVM */
double dummy = 0;
/* Test loop */
for (double i = 0; i <= size; i++) {
/* Declaration and assignment */
double test = i;
/* Dummy assignment to fake JVM */
if(i == size) {
dummy = test;
}
}
return dummy;
}
/**
* Variable is declared before the loop.
*
* @param reps
* @return
*/
public double timeDeclaredBefore(int reps) {
/* Dummy variable needed to workaround smart JVM */
double dummy = 0;
/* Actual test variable */
double test = 0;
/* Test loop */
for (double i = 0; i <= size; i++) {
/* Assignment */
test = i;
/* Not actually needed here, but we need consistent performance results */
if(i == size) {
dummy = test;
}
}
return dummy;
}Tóm tắt: kê khai Trước khi biểu thị hiệu suất tốt hơn - thực sự nhỏ bé - và nó trái với nguyên tắc phạm vi nhỏ nhất. JVM thực sự nên làm điều này cho bạn
Một giải pháp cho vấn đề này có thể là cung cấp một phạm vi biến đổi gói gọn vòng lặp while:
{
// all tmp loop variables here ....
// ....
String str;
while(condition){
str = calculateStr();
.....
}
}Chúng sẽ tự động hủy tham chiếu khi phạm vi bên ngoài kết thúc.
Nếu bạn không cần sử dụng strvòng lặp while (phạm vi liên quan) thì điều kiện thứ hai tức là
while(condition){
String str = calculateStr();
.....
}sẽ tốt hơn vì nếu bạn xác định một đối tượng trên ngăn xếp chỉ khi điều đó conditionlà đúng. Tức là sử dụng nó nếu bạn cần
Tôi nghĩ rằng tài nguyên tốt nhất để trả lời câu hỏi của bạn sẽ là bài viết sau:
Sự khác nhau giữa khai báo biến trước hoặc trong vòng lặp?
Theo sự hiểu biết của tôi điều này sẽ phụ thuộc vào ngôn ngữ. IIRC Java tối ưu hóa điều này, do đó không có sự khác biệt nào, nhưng JavaScript (ví dụ) sẽ thực hiện phân bổ toàn bộ bộ nhớ mỗi lần trong vòng lặp. Trong Java đặc biệt tôi nghĩ rằng lần thứ hai sẽ chạy nhanh hơn khi thực hiện hồ sơ.
Như nhiều người đã chỉ ra,
String str;
while(condition){
str = calculateStr();
.....
}là KHÔNG tốt hơn thế này:
while(condition){
String str = calculateStr();
.....
}Vì vậy, đừng khai báo các biến ngoài phạm vi của chúng nếu bạn không sử dụng lại ...
Khai báo chuỗi str bên ngoài vòng lặp wile cho phép nó được tham chiếu bên trong & bên ngoài vòng lặp while. Khai báo chuỗi str bên trong vòng lặp while cho phép nó chỉ được tham chiếu bên trong vòng lặp while.
Các biến nên được khai báo càng gần nơi chúng được sử dụng càng tốt.
Nó làm cho RAII (Thu nhận tài nguyên là khởi tạo) dễ dàng hơn.
Nó giữ phạm vi của các biến chặt chẽ. Điều này cho phép trình tối ưu hóa hoạt động tốt hơn.
Theo hướng dẫn Phát triển Android của Google, phạm vi biến nên được giới hạn. Vui lòng kiểm tra liên kết này:
Các strbiến sẽ có mặt và dè dặt một số không gian trong bộ nhớ ngay cả sau khi thực hiện dưới mã.
String str;
while(condition){
str = calculateStr();
.....
}Các strbiến sẽ không có sẵn và cũng là bộ nhớ sẽ được phát hành được phân bổ cho strbiến ở bên dưới mã.
while(condition){
String str = calculateStr();
.....
}Nếu chúng tôi theo dõi cái thứ hai chắc chắn điều này sẽ làm giảm bộ nhớ hệ thống của chúng tôi và tăng hiệu suất.
Thực sự, câu hỏi nêu trên là một vấn đề lập trình. Bạn muốn lập trình mã của bạn như thế nào? Nơi nào bạn cần 'STR' để được truy cập? Không có việc sử dụng khai báo một biến được sử dụng cục bộ như một biến toàn cục. Cơ bản về lập trình tôi tin.
Cảnh báo cho hầu hết mọi người trong câu hỏi này: Đây là mã mẫu trong đó bên trong vòng lặp có thể dễ dàng chậm hơn 200 lần trên máy tính của tôi với Java 7 (và mức tiêu thụ bộ nhớ cũng hơi khác nhau). Nhưng đó là về phân bổ và không chỉ phạm vi.
public class Test
{
private final static int STUFF_SIZE = 512;
private final static long LOOP = 10000000l;
private static class Foo
{
private long[] bigStuff = new long[STUFF_SIZE];
public Foo(long value)
{
setValue(value);
}
public void setValue(long value)
{
// Putting value in a random place.
bigStuff[(int) (value % STUFF_SIZE)] = value;
}
public long getValue()
{
// Retrieving whatever value.
return bigStuff[STUFF_SIZE / 2];
}
}
public static long test1()
{
long total = 0;
for (long i = 0; i < LOOP; i++)
{
Foo foo = new Foo(i);
total += foo.getValue();
}
return total;
}
public static long test2()
{
long total = 0;
Foo foo = new Foo(0);
for (long i = 0; i < LOOP; i++)
{
foo.setValue(i);
total += foo.getValue();
}
return total;
}
public static void main(String[] args)
{
long start;
start = System.currentTimeMillis();
test1();
System.out.println(System.currentTimeMillis() - start);
start = System.currentTimeMillis();
test2();
System.out.println(System.currentTimeMillis() - start);
}
}Kết luận: Tùy thuộc vào kích thước của biến cục bộ, sự khác biệt có thể rất lớn, ngay cả với các biến không quá lớn.
Chỉ cần nói rằng đôi khi, bên ngoài hoặc bên trong vòng lặp KHÔNG quan trọng.
bigStuff[(int) (value % STUFF_SIZE)] = value;(Hãy thử một giá trị của 2147483649L)
Tôi nghĩ rằng kích thước của các đối tượng là tốt. Trong một trong những dự án của tôi, chúng tôi đã khai báo và khởi tạo một mảng hai chiều lớn khiến ứng dụng trở thành ngoại lệ ngoài bộ nhớ. Thay vào đó, chúng tôi đã di chuyển khai báo ra khỏi vòng lặp và xóa mảng khi bắt đầu mỗi lần lặp.
Bạn có nguy cơ NullPointerExceptionnếu calculateStr()phương thức của bạn trả về null và sau đó bạn cố gắng gọi một phương thức trên str.
Tổng quát hơn, tránh có các biến với một giá trị null . Bằng cách này, nó mạnh hơn cho các thuộc tính lớp.
NullPointerException.Nếu mã này cố gắng return str;sẽ gặp phải lỗi biên dịch.