假設我有一個HashMap，它將實際的文件對象存儲爲關鍵字，並將該值存儲爲上次修改日期。如果Java是一個文件對象，它如何比較一個Key？
HashMap<File, Long> hashMap = new HashMap<File, Long>();
如果文件（test.log中）在我的HashMap的存在（我已經添加了），但該文件（test.log中）被修改或者後來改變;當我發出替換時，它是否會找到現有的匹配對象，或者是否會改變文件的狀態更改，這將改變對象的性質。因此，我將間接添加一個新的關鍵值對。
hashMap.replace(file, newModifiedTime);
測試具有給定對象相等此抽象路徑名。當且僅當參數不爲null並且是一個與此抽象路徑名錶示相同文件或目錄的抽象路徑名時，才返回true。兩個抽象路徑名是否相等取決於底層系統。
File的.equals()/.hashCode()測試的文件名，所以你的鑰匙是‘安全’。
Javadoc這樣說。
注意：如果您使用的是JDK 7或更高版本，請幫忙：drop File，使用Files/Path。
注2：請注意，如果你是在目錄/foo，new File("bar")和new File("/foo/bar")是不一樣。如果您想確保文件名稱是「完整的」，請使用.getCanonicalFile()。
但是，再次爲自己做個忙，並使用Files。這是好幾個數量級。
存儲的內容有一個密鑰是文件的散列。這實際上並不意味着整個對象被散列。只有Path用於生成File對象的散列。
將對象存儲爲散列表的關鍵字時。它會在內部調用.hashCode()
http://docs.oracle.com/javase/6/docs/api/java/io/File.html#hashCode()
從文檔。
計算此抽象路徑名的哈希碼。因爲抽象路徑名的平等本質上是依賴於系統的，所以它們的哈希碼的計算也是如此。在UNIX系統上， 抽象路徑名的哈希碼等於其 路徑名字符串和十進制值1234321的哈希碼。在Microsoft Windows 系統上，哈希碼等於排除或其路徑名字符串的散列碼 轉換爲小寫字母，並且十進制值 1234321.在降低路徑名字符串的低位時不考慮語言環境。
HashMap使用其鍵的hashCode()方法。並且File.hashCode()這麼做，根據the docs：
計算這個抽象路徑名的哈希碼。因爲抽象路徑名的平等本質上是依賴於系統的，所以它們的哈希碼的計算也是如此。在UNIX系統上， 抽象路徑名的哈希碼等於其 路徑名字符串和十進制值1234321的哈希碼。在Microsoft Windows 系統上，哈希碼等於排除或其路徑名字符串的散列碼 轉換爲小寫字母，並且十進制值 1234321.在降低路徑名字符串的低位時不考慮語言環境。
簡而言之，散列是基於路徑名而不是文件內容計算的。
HashMap使用hashCode()和equals()其類實例的方法被用作鍵，即File你的情況。在File的情況下，它通過將功能委託給具體文件系統包裝來比較抽象路徑。
如果你想改變這種行爲，你應該使用TreeMap並實現自己的自定義比較該文件內容進行比較，最後修改日期等
您是否嘗試過閱讀）File.equals的代碼（？ – Augusto
不，但基於我明確應該有的答案:) –