我在加載AudioBuffer中的兩個300MB MP3文件，然後繼續將它們編碼爲WAV文件。編碼過程（發生在網絡工作者）的某個地方，瀏覽器因爲內存不足而崩潰。如何捕捉和處理Chrome內存崩潰？
WAV文件比MP3文件大3倍左右，所以就需要1.8GB〜額外的空間做轉換。
這些文件可以有任何大小，因爲它們是用戶選擇上傳的mp3文件，所以它們可以是10MB或350MB。這意味着內存可能會或可能不足夠。如果它不夠，我該如何簡單地捕捉並處理錯誤，而不是讓瀏覽器崩潰？
我會限制用戶到一個特定的項目（所有文件組合）的大小，但它似乎最大的內存限制隨操作系統，操作系統架構，瀏覽器版本和瀏覽器架構而變化，這使得幾乎不可能定義這種限制。
不幸的是，沒有辦法「發現並處理」內存不足的錯誤，對不起。根據設計，出於安全原因，V8在無法分配所需內存時總會崩潰。
JavaScript堆的內存限制是根據機器具有的物理內存量動態確定的。多年來，「足夠」的RAM在32位桌面架構上爲700 MB，在64位架構上爲1400 MB;不過最近的Chrome/V8版本已經在調整策略，現在64位上限爲2048MB。所以是的，具體細節可能會隨着時間而改變。操作系統並不重要，但（至少不是JavaScript堆）。
我不完全確定AudioBuffers是否計入V8的堆棧限制（V8本身不知道AudioBuffers，它們是由嵌入程序即Blink實現的）。
請注意，您可能無法使用最多達到最大值的每個最後一個字節。一些內存用於內部元數據;並且當你動態地增長數組等等時，它們會以塊的形式增長，這使得即使增長前的大小不是「最大減1」，增長嘗試也可能達到極限。在32位平臺上，嘗試分配單個大對象也可能由於地址空間耗盡而失敗：在爲此分配了大量隨機選擇的頁面並且在該過程的整個生命週期中分配了大量對象之後，可能根本沒有足夠的空間連續的大塊地址空間可用於分配大小爲幾百兆的大對象，即使尚未達到堆限制。
旁註：「三倍大」？對於常用的MP3比特率，我預計WAV文件會高出10倍。
這個答案（https://stackoverflow.com/a/34667584/5086286）表明，操作系統和瀏覽器版本有內存限制的影響，儘管他可能是說整個標籤的內存，而你說話特別是關於JS堆大小。我認爲'AudioBuffers'包含在V8的堆中，因爲當我採用「堆快照」時，它包含在內。至於WAV編碼，我將轉換爲16位文件，這可能解釋爲什麼它只有3-4倍大。我將測試JS堆限制，然後我會回覆你。非常感謝你的幫助！ – maximedupre
我目前有一個工作頁面，其JS堆大小爲1503MB（根據堆快照），這使我相信1400MB不是限制。 – maximedupre
呵，好點。原來Chrome M56的限制是1400 MB，而M57將其限制爲2048 MB。我會更新我的答案。 – jmrk