摘要:前言開發(fā)中,正常情況下,在執(zhí)行了代碼塊之后,中的代碼一定會執(zhí)行。上述在主線程和守護線程中都設置的原因是怕線程方法還未開始執(zhí)行主線程就退出了,這樣的話代碼塊中的內容都不會執(zhí)行。當然不是說守護線程中的代碼一定不會執(zhí)行。
前言
Java開發(fā)中,正常情況下,在執(zhí)行了try代碼塊之后,finally中的代碼一定會執(zhí)行。我們實際開發(fā)也經(jīng)常會利用這個特性,在finally中來執(zhí)行一些特殊的操作,比如:釋放資源、釋放鎖等。
demo
public class Finally { public static void main(String[] args) { try { //正常業(yè)務邏輯 System.out.println("I am try"); throw new RuntimeException("I am RuntimeExecption"); } catch (Exception e) { //異常處理 System.out.println("I am Exception -> " + e.getMessage()); } finally { //釋放資源等 System.out.println("I am Finally"); } } }
execute
I am try I am Exception -> I am RuntimeExecption I am Finally
那么是不是finally中的代碼一定會被執(zhí)行呢?
其實不然,目前作者了解到有兩種情況下,finally中的代碼不會被執(zhí)行(不考慮try之前出現(xiàn)異常或者return的情況,換言之,在try之前出現(xiàn)異常或者return時,try對應的finally中的內容不會被執(zhí)行)
finally之前虛擬機被停止demo
public class Finally { public static void main(String[] args) { try { //正常業(yè)務邏輯 System.out.println("I am try"); throw new RuntimeException("I am RuntimeExecption"); } catch (Exception e) { //異常處理 System.out.println("I am Exception -> " + e.getMessage()); System.exit(1);//異常關閉虛擬機 } finally { //釋放資源等 System.out.println("I am Finally"); } } }
execute
I am try I am Exception -> I am RuntimeExecption
上面的代碼在出現(xiàn)了異常之后,使用System.exit(1)退出關閉虛擬機,finally中的代碼當然無法執(zhí)行。
守護線程中的finallydemo
public class Finally { public static void main(String[] args) throws Exception { Thread thread = new Thread(new Runnable() { public void run() { try { //正常業(yè)務邏輯 System.out.println("I am try"); Thread.sleep(1000); } catch (Exception e) { //異常處理 System.out.println("I am Exception -> " + e.getMessage()); } finally { //釋放資源等 System.out.println("I am Finally"); } } }); thread.setDaemon(true); thread.start(); Thread.sleep(1000); System.out.println("end"); } }
execute
I am try end
使用setDaemon(true)方法來設置線程為守護線程,從打印結果中可以看到,守護線程中,try代碼塊中的代碼執(zhí)行了,finally代碼塊未必執(zhí)行。主要原因是因為守護線程會隨著所有非守護線程的退出而退出。上述在主線程和守護線程中都設置sleep(1000)的原因是怕線程run()方法還未開始執(zhí)行主線程就退出了,這樣的話try代碼塊中的內容都不會執(zhí)行。當然不是說守護線程中的finally代碼一定不會執(zhí)行。
總結java中,如果想要執(zhí)行try中的代碼之后,不允許再執(zhí)行finally中的代碼,有以下兩種方式:
使用System.exit(1)來退出虛擬機
把當前執(zhí)行trycatchfinally代碼的線程設置為守護線程
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/74364.html
摘要:奇怪的代碼行這里第一行為什么加了而且還要聲明一個局部變量探尋緣由經(jīng)過搜索找到的解釋本質上是由于內存模型和之間的不同如果我們直接使用函數(shù)內使用的執(zhí)行時序函數(shù)僅會保存的指針會在使用的地方通過指針獲取對象然后再調用相應方法例如好像還可以接受嘛但 奇怪的代碼 JDK 1.8 | java.util.concurrent.locks.ReentrantLock | 125行 /** * Pe...
摘要:子線程往消息隊列發(fā)送消息,并且往管道文件寫數(shù)據(jù),主線程即被喚醒,從管道文件讀取數(shù)據(jù),主線程被喚醒只是為了讀取消息,當消息讀取完畢,再次睡眠。因此的循環(huán)并不會對性能有過多的消耗。 說下你所知道的設計模式與使用場景 a.建造者模式: 將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創(chuàng)建不同的表示。 使用場景比如最常見的AlertDialog,拿我們開發(fā)過程中舉例,比如Camera...
摘要:廣州三本大三在讀,在廣州找實習。這篇文章其實主要是記錄一下自己的面試經(jīng)歷,希望大家看完之后能有所了解進入中小公司究竟需要什么水平。時間復雜度盡量低一些使用快排的,將給出的隨機數(shù)做基準值返回的坐標就是了。 前言 只有光頭才能變強 這陣子跑去面試Java實習生啦~~~我來簡單介紹一下背景吧。 廣州三本大三在讀,在廣州找實習。大學開始接觸編程,一個非常平庸的人。 在學習編程時,跟我類似的人應...
閱讀 2485·2021-11-24 09:39
閱讀 3528·2019-08-30 15:53
閱讀 602·2019-08-29 15:15
閱讀 2909·2019-08-26 13:23
閱讀 3224·2019-08-26 10:48
閱讀 650·2019-08-26 10:31
閱讀 776·2019-08-26 10:30
閱讀 2370·2019-08-23 18:32