如圖是程式運行了一段時間後丟擲來的一個bug, 剛開始看這個bug的時候各種網上找答案, 無外乎教你怎麼改ulimit(就是linux最大開啟檔案數), 當然不是說改這個沒有用, 作為程式開發者來說, 如果程式執行出現了bug則必然是程式的問題, 畢竟linux系統已經相當成熟, 它不會欺騙你(作為小菜鳥的我也是剛認識到這一點).

    今天遇到的這種bug, 的確是程式上的原因. 具體什麼原因, 下面開始我的表演.

 我們知道linux中對於某個程序開啟的檔案控制代碼是有限制的, 這裡的意識不是指簡單new一個File物件.其實你new 一億個檔案物件放在那邊, linux都不會來警告你. 這裡的限制是我們new 了一個FIle, 並且使用了這個控制代碼搞事情. 如下面的程式碼

import org.testng.annotations.Test;

import java.io.*;

/**
 * Created by fire on 2018-03-02 14:45:02.
 */
public class File_new {

    @Test
    public void test1(){
        File f1 = new File("G:/state/a.txt");
        File f2 = new File("G:/state/b.txt");
        File f3 = new File("G:/state/c.txt"
 
);
        File f4 = new File("G:/state/d.txt");

        String line = null;
        BufferedReader br = null;
        try{
            br = new BufferedReader(new InputStreamReader(new FileInputStream(f1)));
            f1.delete();  //
            while ((line = br.readLine()) != null){
                System.out
 
.println(line);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }finally {
            if(br != null){
                try {
                    br.close();
                    br = null;
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

    上面程式碼new了很多File物件, 但是真正開啟的只有f1. linux限制的就是這個f1控制代碼.  然餓, 如果, 像上面的程式碼這樣寫個10000遍, 則一定會被linux限制到, 因為這裡就存在了一個控制代碼洩漏的問題.  當我們把開啟的控制代碼刪除的時候, 一定要記得把用到它的所有資源都要關閉掉, 不然一定會造成控制代碼洩漏. 不信可以在linux 用 lsof -p + 程序的PID 檢視. 

    所以, 我們在對檔案操作是, 一定要記得, 先關資源後刪檔案, 否則一定會造成控制代碼洩漏!!!  謹記~~~~