代碼審計(jì)：顧名思義就是檢查源代碼中的安全缺陷，檢查程序源代碼是否存在安全隱患，或者有編碼不規(guī)范的地方，通過(guò)自動(dòng)化工具或者人工審查的方式，對(duì)程序源代碼逐條進(jìn)行檢查和分析，發(fā)現(xiàn)這些源代碼缺陷引發(fā)的安全漏洞，并提供代碼修訂措施和建議。
創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的蘆淞網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
下面有關(guān)Java代碼安全性的敘述，( )是對(duì)的。 Ⅰ：字節(jié)碼校驗(yàn)器加載查詢執(zhí)行需要的所有類。 Ⅱ：運(yùn)行時(shí)解釋器執(zhí)行代碼。 Ⅲ：在運(yùn)行時(shí)，字節(jié)碼被加載，驗(yàn)證后在解釋器里面運(yùn)行。 Ⅳ：類加載器通過(guò)分離本機(jī)文件系統(tǒng)的類和從網(wǎng)絡(luò)導(dǎo)入的類增加安全性。
A．Ⅱ、Ⅲ
B．Ⅱ、Ⅲ、Ⅳ
C．Ⅰ、Ⅲ、Ⅳ
D．Ⅲ、Ⅳ
請(qǐng)幫忙給出正確答案和分析，謝謝！
正確答案：B
解析：該題考查考生對(duì)Java程序代碼安全性的掌握。Java程序運(yùn)行的過(guò)程是這樣的：類加載器加載程序運(yùn)行所需要的所有類，它通過(guò)區(qū)分本機(jī)文件系統(tǒng)的類和網(wǎng)絡(luò)系統(tǒng)導(dǎo)入的類增加安全性，這可以限制任何的特洛伊木馬程序，因?yàn)楸緳C(jī)類總是先被加載，一旦所有的類被加載完，執(zhí)行文件的內(nèi)存劃分就固定了，在這個(gè)時(shí)候，特定的內(nèi)存地址被分配給對(duì)應(yīng)的符號(hào)引用，查找表也被建立，由于內(nèi)存劃分發(fā)生在運(yùn)行時(shí)，解釋器在受限制的代碼區(qū)增加保護(hù)，防止未授權(quán)的訪問(wèn)；然后字節(jié)碼校驗(yàn)器進(jìn)行校驗(yàn)，主要執(zhí)行下面的檢查，類是否符合JVM規(guī)范的類文件格式，有沒(méi)有違反訪問(wèn)限制，代碼有沒(méi)有造成堆棧的上溢或者下溢，所有操作代碼的參數(shù)類型是否都是正確的，有沒(méi)有非法的數(shù)據(jù)類型轉(zhuǎn)換(例如將整型數(shù)轉(zhuǎn)換成對(duì)象類型)發(fā)生；校驗(yàn)通過(guò)的字節(jié)碼被解釋器執(zhí)行，解釋器在必要時(shí)通過(guò)運(yùn)行時(shí)系統(tǒng)執(zhí)行對(duì)底層硬件的相應(yīng)調(diào)用。
靜態(tài)測(cè)試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，充分發(fā)揮人的邏輯思維優(yōu)勢(shì)，也可以借助軟件工具自動(dòng)進(jìn)行。代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設(shè)計(jì)的一致性， 代碼對(duì)標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面；可以發(fā)現(xiàn)違背程序編寫標(biāo)準(zhǔn)的問(wèn)題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風(fēng)格的問(wèn)題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語(yǔ)法檢查和程序結(jié)構(gòu)檢查等內(nèi)容?！??？戳艘幌盗械撵o態(tài)代碼掃描或者叫靜態(tài)代碼分析工具后，總結(jié)對(duì)工具的看法：靜態(tài)代碼掃描工具，和編譯器的某些功能其實(shí)是很相似的，他們也需要詞法分析，語(yǔ)法分析，語(yǔ)意分析...但和編譯器不一樣的是他們可以自定義各種各樣的復(fù)雜的規(guī)則去對(duì)代碼進(jìn)行分析。
javaWeb安全漏洞及處理方式
關(guān)注
轉(zhuǎn)載自：
1、SQL注入攻擊
SQL注入攻擊就是通過(guò)把SQL命令插入到Web表單提交或輸入域名或頁(yè)面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來(lái)說(shuō)，它是利用現(xiàn)有應(yīng)用程序，將(惡意)的SQL命令注入到后臺(tái)數(shù)據(jù)庫(kù)引擎執(zhí)行的能力，它可以通過(guò)在Web表單中輸入(惡意)SQL語(yǔ)句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫(kù)，而不是按照設(shè)計(jì)者意圖去執(zhí)行SQL語(yǔ)句。
隨著B/S框架結(jié)構(gòu)在系統(tǒng)開發(fā)中的廣泛應(yīng)用，惡意攻擊者利用SQL命令在Web表單中輸入合法的字符或查詢字符串來(lái)欺騙服務(wù)器執(zhí)行SQL命令。當(dāng)注入攻擊得逞后，Web程序?qū)⑿孤洞罅坑脩綦[私數(shù)據(jù)和數(shù)據(jù)庫(kù)中數(shù)據(jù)結(jié)構(gòu)。攻擊者能夠獲得系統(tǒng)較高的訪問(wèn)權(quán)限，進(jìn)行破壞操作。
SQL注入可以分為平臺(tái)層注入和代碼層注入。前者由不安全的數(shù)據(jù)庫(kù)配置或數(shù)據(jù)庫(kù)平臺(tái)的漏洞所致;后者主要是由于程序員對(duì)輸入未進(jìn)行細(xì)致地過(guò)濾，從而執(zhí)行了非法的數(shù)據(jù)查詢?；诖?，SQL注入的產(chǎn)生原因通常表現(xiàn)在以下幾方面:
1）不當(dāng)?shù)念愋吞幚?
2）不安全的數(shù)據(jù)庫(kù)配置;
3）不合理的查詢集處理;
4）不當(dāng)?shù)腻e(cuò)誤處理;
5）轉(zhuǎn)義字符處理不合適;
6) 多個(gè)提交處理不當(dāng)。
解決方法:
數(shù)據(jù)庫(kù)安全通信包括SQL注入攻擊的防范、安全設(shè)置、異常信息處理三個(gè)方面。
1.服務(wù)端Filter對(duì)訪問(wèn)者輸入的字符進(jìn)行過(guò)濾檢驗(yàn)，但是攻擊者經(jīng)常把危險(xiǎn)字符潛藏在用戶輸入的有效字符中完 成過(guò)濾檢驗(yàn)。
2.通過(guò)正則表達(dá)式對(duì)頁(yè)面的文本框輸入的數(shù)據(jù)進(jìn)行限制可以減少過(guò)濾檢驗(yàn)存在的漏洞。
3.使用prepareStatment預(yù)編譯sql語(yǔ)句
2、XSS跨站腳本攻擊
跨站腳本（Cross-site scripting，簡(jiǎn)稱XSS），是一種迫使Web站點(diǎn)回顯可執(zhí)行代碼的攻擊技術(shù)，而這些可執(zhí)行代碼由攻擊者提供、最終為用戶瀏覽器加載。不同于大多數(shù)攻擊（一般只涉及攻擊者和受害者），XSS涉及到三方，即攻擊者、客戶端與網(wǎng)站。XSS的攻擊目標(biāo)是為了盜取客戶端的cookie或者其他網(wǎng)站用于識(shí)別客戶端身份的敏感信息。獲取到合法用戶的信息后，攻擊者甚至可以假冒最終用戶與網(wǎng)站進(jìn)行交互。
XSS 屬于被動(dòng)式的攻擊。攻擊者先構(gòu)造一個(gè)跨站頁(yè)面，利用SCRIPT、IMG、IFRAME等各種方式使得用戶瀏覽這個(gè)頁(yè)面時(shí)，觸發(fā)對(duì)被攻擊站點(diǎn)的HTTP 請(qǐng)求。此時(shí)，如果被攻擊者如果已經(jīng)在被攻擊站點(diǎn)登錄，就會(huì)持有該站點(diǎn)cookie。這樣該站點(diǎn)會(huì)認(rèn)為被攻擊者發(fā)起了一個(gè)HTTP請(qǐng)求。而實(shí)際上這個(gè)請(qǐng)求是在被攻擊者不知情情況下發(fā)起的，由此攻擊者在一定程度上達(dá)到了冒充被攻擊者的目的。精心的構(gòu)造這個(gè)攻擊請(qǐng)求，可以達(dá)到冒充發(fā)文，奪取權(quán)限等多個(gè)攻擊目的。在常見的攻擊實(shí)例中，這個(gè)請(qǐng)求是通過(guò)script 來(lái)發(fā)起的，因此被稱為Cross Site Script。
XSS漏洞成因是由于動(dòng)態(tài)網(wǎng)頁(yè)的Web應(yīng)用對(duì)用戶提交請(qǐng)求參數(shù)未做充分的檢查過(guò)濾，允許用戶在提交的數(shù)據(jù)中摻入HTML代碼（最主要的是“”、“”），然后未加編碼地輸出到第三方用戶的瀏覽器，這些攻擊者惡意提交代碼會(huì)被受害用戶的瀏覽器解釋執(zhí)行。
分為三種類型：
1）反射型（數(shù)據(jù)流向：瀏覽器 -后端 - 瀏覽器）
反射型XSS腳本攻擊即如我們上面所提到的XSS跨站腳本攻擊方式，該類型只是簡(jiǎn)單地將用戶輸入的數(shù)據(jù)直接或未經(jīng)過(guò)完善的安全過(guò)濾就在瀏覽器中進(jìn)行輸出，導(dǎo)致輸出的數(shù)據(jù)中存在可被瀏覽器執(zhí)行的代碼數(shù)據(jù)。由于此種類型的跨站代碼存在于URL中，所以黑客通常需要通過(guò)誘騙或加密變形等方式，將存在惡意代碼的鏈接發(fā)給用戶，只有用戶點(diǎn)擊以后才能使得攻擊成功實(shí)施。
2）存儲(chǔ)型（數(shù)據(jù)流向是：瀏覽器 -后端 - 數(shù)據(jù)庫(kù) - 后端- 瀏覽器）
存儲(chǔ)型XSS腳本攻擊是指Web應(yīng)用程序會(huì)將用戶輸入的數(shù)據(jù)信息保存在服務(wù)端的數(shù)據(jù)庫(kù)或其他文件形式中，網(wǎng)頁(yè)進(jìn)行數(shù)據(jù)查詢展示時(shí)，會(huì)從數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)內(nèi)容，并將數(shù)據(jù)內(nèi)容在網(wǎng)頁(yè)中進(jìn)行輸出展示，因此存儲(chǔ)型XSS具有較強(qiáng)的穩(wěn)定性。
存儲(chǔ)型XSS腳本攻擊最為常見的場(chǎng)景就是在博客或新聞發(fā)布系統(tǒng)中，黑客將包含有惡意代碼的數(shù)據(jù)信息直接寫入文章或文章評(píng)論中，所有瀏覽文章或評(píng)論的用戶，都會(huì)在他們客戶端瀏覽器環(huán)境中執(zhí)行插入的惡意代碼。
3）基于DOM（數(shù)據(jù)流向是：URL--瀏覽器 ）
基于DOM的XSS跨站腳本攻擊是通過(guò)修改頁(yè)面DOM節(jié)點(diǎn)數(shù)據(jù)信息而形成的XSS跨站腳本攻擊。不同于反射型XSS和存儲(chǔ)型XSS，基于DOM的XSS跨站腳本攻擊往往需要針對(duì)具體的javascript DOM代碼進(jìn)行分析，并根據(jù)實(shí)際情況進(jìn)行XSS跨站腳本攻擊的利用。
解決方法：
1).輸入過(guò)濾。對(duì)用戶的所有輸入數(shù)據(jù)進(jìn)行檢測(cè)，比如過(guò)濾其中的“”、“”、“/”等可能導(dǎo)致腳本注入的特殊字符，或者過(guò)濾“script”、“javascript”等腳本關(guān)鍵字，或者對(duì)輸入數(shù)據(jù)的長(zhǎng)度進(jìn)行限制等等。同時(shí)，我們也要考慮用戶可能繞開ASCII碼，使用十六進(jìn)制編碼來(lái)輸入腳本。因此，對(duì)用戶輸入的十六進(jìn)制編碼，我們也要進(jìn)行相應(yīng)的過(guò)濾。只要能夠嚴(yán)格檢測(cè)每一處交互點(diǎn)，保證對(duì)所有用戶可能的輸入都進(jìn)行檢測(cè)和XSS過(guò)濾，就能夠有效地阻止XSS攻擊。
2).輸出編碼。通過(guò)前面對(duì)XSS攻擊的分析，我們可以看到，之所以會(huì)產(chǎn)生XSS攻擊，就是因?yàn)閃eb應(yīng)用程序?qū)⒂脩舻妮斎胫苯忧度氲侥硞€(gè)頁(yè)面當(dāng)中，作為該頁(yè)面的HTML代碼的一部分。因此，當(dāng)Web應(yīng)用程序?qū)⒂脩舻妮斎霐?shù)據(jù)輸出到目標(biāo)頁(yè)面中時(shí)，只要用HtmlEncoder等工具先對(duì)這些數(shù)據(jù)進(jìn)行編碼，然后再輸出到目標(biāo)頁(yè)面中。這樣，如果用戶輸入一些HTML的腳本，也會(huì)被當(dāng)成普通的文字，而不會(huì)成為目標(biāo)頁(yè)面HTML代碼的一部分得到執(zhí)行.
3、CSRF跨站請(qǐng)求偽造漏洞防護(hù)
CSRF是CrossSite Request Forgery的縮寫，乍一看和XSS差不多的樣子，但是其原理正好相反，XSS是利用合法用戶獲取其信息，而CSRF是偽造成合法用戶發(fā)起請(qǐng)求。
字面理解意思就是在別的站點(diǎn)偽造了一個(gè)請(qǐng)求。專業(yè)術(shù)語(yǔ)來(lái)說(shuō)就是在受害者訪問(wèn)一個(gè)網(wǎng)站時(shí)，其 Cookie 還沒(méi)有過(guò)期的情況下，攻擊者偽造一個(gè)鏈接地址發(fā)送受害者并欺騙讓其點(diǎn)擊，從而形成 CSRF 攻擊。
根據(jù)HTTP協(xié)議，在HTTP頭中有一個(gè)字段叫Referer，它記錄了該HTTP請(qǐng)求的來(lái)源地址。在通常情況下，訪問(wèn)一個(gè)安全受限頁(yè)面的請(qǐng)求必須來(lái)自于同一個(gè)網(wǎng)站。
解決方案：
配置FILTER攔截用戶所有請(qǐng)求(POST/GET)，對(duì)用戶請(qǐng)求Referer頭URL進(jìn)行合法性校驗(yàn)。
4、URL鏈接注入漏洞防護(hù)
鏈接注入是修改站點(diǎn)內(nèi)容的行為，其方式為將外部站點(diǎn)的 URL 嵌入其中，或?qū)⒂幸资芄舻恼军c(diǎn)中的腳本 的 URL 嵌入其中。將URL 嵌入易受攻擊的站點(diǎn)中，攻擊者便能夠以它為平臺(tái)來(lái)啟動(dòng)對(duì)其他站點(diǎn)的攻擊，以及攻擊這個(gè)易受攻擊的站點(diǎn)本身。
解決方案：
1，二次驗(yàn)證，進(jìn)行重要敏感操作時(shí)，要求用戶進(jìn)行二次驗(yàn)證。
2，驗(yàn)證碼，進(jìn)行重要敏感操作時(shí)，加入驗(yàn)證碼。
3，驗(yàn)證 HTTP 的 Referer 字段。
4，請(qǐng)求地址中添加 Token 并驗(yàn)證。
5，HTTP 頭中自定義屬性并驗(yàn)證。
5、會(huì)話COOKIE中缺少HttpOnly防護(hù)
會(huì)話cookie中缺少HttpOnly屬性會(huì)導(dǎo)致攻擊者可以通過(guò)程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。
HttpOnly是微軟對(duì)cookie做的擴(kuò)展，該值指定cookie是否可通過(guò)客戶端腳本訪問(wèn)。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。
如果在Cookie中沒(méi)有設(shè)置HttpOnly屬性為true，可能導(dǎo)致Cookie被竊取。竊取的Cookie可以包含標(biāo)識(shí)站點(diǎn)用戶的敏感信息。
如果在Cookie中設(shè)置HttpOnly屬性為true，兼容瀏覽器接收到HttpOnly cookie，那么客戶端通過(guò)程序(JS腳本、Applet等)將無(wú)法讀取到Cookie信息，這將有助于緩解跨站點(diǎn)腳本威脅。
解決方案：
配置filter攔截器，將服務(wù)器端返回請(qǐng)求，向所有會(huì)話cookie中添加“HttpOnly”屬性。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.setHeader("SET-COOKIE","JSESSIONID=" + sessionid + "; HttpOnly");
6、點(diǎn)擊劫持漏洞(Clickjacking)防護(hù)
點(diǎn)擊劫持是一種視覺上的欺騙手段，攻擊者使用一個(gè)透明的、不可見的iframe，覆蓋在一個(gè)網(wǎng)頁(yè)上，然后誘使用戶在該網(wǎng)頁(yè)上進(jìn)行操作，此時(shí)用戶在不知情的情況下點(diǎn)擊了透明的iframe頁(yè)面。通過(guò)調(diào)整iframe頁(yè)面的位置，可以誘使用戶恰好點(diǎn)擊在iframe頁(yè)面的一些功能性按鈕上。
解決方案：
配置FILTER攔截器，在服務(wù)器端返回請(qǐng)求中，使用一個(gè)HTTP頭“X-Frame-Options”值為SAMEORIGIN-同源策略 ，則frame頁(yè)面的地址只能為同源域名下面的頁(yè)面，防止點(diǎn)擊劫持漏洞發(fā)生。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.addHeader("x-frame-options","SAMEORIGIN");
7、HTTP host 頭攻擊漏洞
使用HTTP代理工具，可以篡改HTTP報(bào)文頭部中HOST字段時(shí)，該值可被注入惡意代碼。因?yàn)樾枰刂瓶蛻舳说妮斎耄试撀┒摧^難利用。
解決方案：
配置FILTER攔截器，對(duì)請(qǐng)求輸入HOST頭信息進(jìn)行信息安全性校驗(yàn)，防止HOST頭信息被惡意篡改利用。
示例代碼：
HttpServletRequest request =(HttpServletRequest)servletRequest;
//主機(jī)ip和端口 或 域名和端口
String myhosts = request.getHeader("host");
if(!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx:xxxx")StringUtils.equals(myhosts,"xx.xx.xxx.xxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx" ){
logger.error("======訪問(wèn)host非法，已攔截======");
response.sendRedirect(request.getContextPath() + "/login.jsp");
return;
}
8、越權(quán)訪問(wèn)漏洞防護(hù)
越權(quán)訪問(wèn)（Broken Access Control，簡(jiǎn)稱BAC）是Web應(yīng)用程序中一種常見的漏洞，分為垂直越權(quán)訪問(wèn)和水平越權(quán)訪問(wèn)。垂直越權(quán)是指不同用戶級(jí)別之間的越權(quán)，如普通用戶執(zhí)行管理員用戶的權(quán)限。水平越權(quán)是指相同級(jí)別用戶之間的越權(quán)操作。
Web應(yīng)用程序如果存在越權(quán)訪問(wèn)漏洞，可能導(dǎo)致以下危害：
1）導(dǎo)致任意用戶敏感信息泄露；
2）導(dǎo)致任意用戶信息被惡意修改或刪除。
解決方案：
配置FILTER攔截器，對(duì)請(qǐng)求所有URL進(jìn)行攔截，對(duì)于需要進(jìn)行授權(quán)的URL進(jìn)行權(quán)限校驗(yàn)，防止用戶越權(quán)訪問(wèn)系統(tǒng)資源。
9.弱口令漏洞
解決方案：最好使用至少6位的數(shù)字、字母及特殊字符組合作為密碼。數(shù)據(jù)庫(kù)不要存儲(chǔ)明文密碼，應(yīng)存儲(chǔ)MD5加密后的密文，由于目前普通的MD5加密已經(jīng)可以被破解，最好可以多重MD5加密，或者多種加密方式疊加組合。
10．JSP頁(yè)面拋出的異常可能暴露程序信息。
有經(jīng)驗(yàn)的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構(gòu)、程序的物理路徑、SQL注入爆出來(lái)的信息等。
解決方案：自定義一個(gè)Exception，將異常信息包裝起來(lái)不要拋到頁(yè)面上。
11.本地緩存漏洞
合法用戶“注銷”后，在未關(guān)閉瀏覽器的情況下，點(diǎn)擊瀏覽器“后退”按鈕，可從本地頁(yè)面緩存中讀取數(shù)據(jù)，繞過(guò)了服務(wù)端filter過(guò)濾。
解決方案：配置filter對(duì)存放敏感信息的頁(yè)面限制頁(yè)面緩存。如：
httpResponse.setHeader("Cache-Control","no-cache");
httpResponse.setHeader("Cache-Control","no-store");
httpResponse.setDateHeader("Expires",0);
httpResponse.setHeader("Pragma","no-cache");
12.文件上傳漏洞。
前臺(tái)僅使用JS對(duì)文件后綴做了過(guò)濾，這只能針對(duì)普通的用戶，而惡意攻擊者完全可以修改表單去掉JS校驗(yàn)。
13.Java WEB容器默認(rèn)配置漏洞。
如TOMCAT后臺(tái)管理漏洞，默認(rèn)用戶名及密碼登錄后可直接上傳war文件獲取webshell。
解決方案：最好刪除，如需要使用它來(lái)管理維護(hù)，可更改其默認(rèn)路徑，口令及密碼。
Java語(yǔ)言包含三種核心機(jī)制：Java 虛擬機(jī)、垃圾收集機(jī)制和代碼安全檢測(cè)。
1、Java 虛擬機(jī)(Java Virtual Machine，JVM)
在一臺(tái)計(jì)算機(jī)上由軟件或硬件模擬的計(jì)算機(jī)。Java虛擬機(jī)讀取并處理經(jīng)編譯過(guò)的平臺(tái)無(wú)關(guān)的字節(jié)碼class文件。
2、垃圾收集機(jī)制(Garbage collection)
在C/C++ 等語(yǔ)言中，由程序員負(fù)責(zé)回收無(wú)用內(nèi)存。Java語(yǔ)言解除了程序員回收無(wú)用內(nèi)存空間的責(zé)任。它提供一種系統(tǒng)級(jí)線程跟蹤存儲(chǔ)空間的分配情況。并在JVM的空閑時(shí)，檢查并釋放那些可被釋放的存儲(chǔ)器空間。垃圾收集在Java程序運(yùn)行過(guò)程中自動(dòng)進(jìn)行，程序員無(wú)法精確控制和干預(yù)。
3、代碼安全性檢測(cè)(Code Security)
Java執(zhí)行代碼的時(shí)候，由JVM對(duì)運(yùn)行的代碼進(jìn)行安全性檢測(cè)，當(dāng)進(jìn)行一些非法操作的時(shí)候，比如修改一些系統(tǒng)設(shè)置的時(shí)候，JVM會(huì)發(fā)出警告。
重慶分公司
重慶分公司
