2023-09-09 23:59:00 62 0

- N +

spring常用注解怎么定義的 java的三種注釋方式

大家好,今天小編來為大家解答以下的問題，關于spring常用注解怎么定義的，java的三種注釋方式這個很多人還不知道，現在讓我們一起來看看吧！

java中注解方式是否是侵入

謝邀，作為一個Java軟件工程師對這個問題有自己的見解。

先搞清楚侵入性的概念當你的代碼引入了一個組件,導致其它代碼或者設計,要做相應的更改以適應新組件.這樣的情況我們就認為這個新組件具有侵入性。

顯然，如果設計的代碼對原有代碼邏輯有代碼侵入的話，是一個糟糕的設計方式。什么是侵入性？個人認為就是一旦你這段添加的代碼出現異常對原本的代碼會有極大影響，那你這段代碼侵入性就太明顯了。

而注解對代碼是否有侵入性呢？

要知道注解是從老版jdk就有的一個語法特性，目前廣泛運用在各大框架中間件的開發中，比如我們最常用的spring框架，編程時service和autoware等注解幾乎是必用的。如果說注解式編程對代碼有過度侵入性，我想甲骨文公司也不會去創造注解這種東西。顯然，注解本身并不會對代碼造成侵入，反而他的設計是為了解耦合，通過代理等方式將需要引入的組件添加到原邏輯中。

但是注解一定不會侵入嗎？

答案是否定的，注解本身其實不用糾結會不會侵入，而是對注解使用過程中的開發者，是否會寫出侵入性極強的代碼。用注解完全可以寫出侵入式的代碼，比如在寫spring的aop時，后置處理的代碼有bug，那必然會導致原邏輯不能正常進行，這就是一種侵入，而且還影響很大。

宇文哥習慣性總結:注解是一件利器，用的好代碼可以低耦合，用的不好，就會造成侵入性極強，沒有最好的技術只有更好的編碼者。

關注@極客宇文氏一名熱心有料的Java軟件工程師。

spring創建應用組件行為稱為

Spring創建應用組件之間的行為通常稱為裝配,Spring有很多裝配的方式,xml文件的裝配方式,Java注解配置方式。

spring注解原理

注解（Annotation）提供了一種安全的類似注釋的機制，為我們在代碼中添加信息提供了一種形式化得方法，使我們可以在稍后某個時刻方便的使用這些數據（通過解析注解來使用這些數據），用來將任何的信息或者元數據與程序元素（類、方法、成員變量等）進行關聯。其實就是更加直觀更加明了的說明，這些說明信息與程序業務邏輯沒有關系，并且是供指定的工具或框架使用的。Annotation像一種修飾符一樣，應用于包、類型、構造方法、方法、成員變量、參數及本地變量的申明語句中。

Annotation其實是一種接口。通過java的反射機制相關的API來訪問Annotation信息。相關類（框架或工具中的類）根據這些信息來決定如何使用該程序元素或改變它們的行為。Java語言解釋器在工作時會忽略這些Annotation，因此在JVM中這些Annotation是“不起作用”的，只能通過配套的工具才能對這些Annotation類型的信息進行訪問和處理。

springboot跳轉頁面的注解是哪個

在SpringBoot中，用于跳轉頁面的注解是`@RequestMapping`，其主要作用是將HTTP請求映射到控制器的處理方法，并可以指定返回的視圖名稱或視圖路徑。

但是在SpringBoot2.0之后，為了規范，Spring官方推薦使用更為明確的注解`@GetMapping`、`@PostMapping`等來替代`@RequestMapping`來標記請求的方法。所以，一般情況下我們會使用`@GetMapping`注解來進行頁面的跳轉。

SpringBoot中，@Autowired和@Resource使用起來到底有什么區別

這個問題也有一段時間了，當初也就隨手一寫，直到最近還有網友在看，為了保證大家看的時候不會出現理解方面的問題，于2021-5-10編輯一次，希望能更加嚴謹一點，至少不會誤導大家。

首先，這個問題有點不準確，這2個注解是使用Spring框架過程中常用的注解，而SpringMVC和SpringBoot等框架都是基于Spring的進階框架，并沒有對這2個注解的使用進行修改或者調整，所以，只討論Spring框架如何處理這2個注解即可，而不是討論在SpringBoot中的使用區別。

【結論】在絕大部分情況下，使用這2個注解的任何一個都可以實現自動裝配，在使用方面是無感的。

如果要討論區別，基本上就是2點：

所屬不同：@Resource注解是javax包的；@Autowired是Spring聲明的；裝配機制不同：@Resource會優先byName來裝配，即使名稱不匹配，也會嘗試byType來裝配；@Autowired則是先查找匹配類型對象的數量，如果有且僅有1個，則直接裝配，如果為0個，則無法裝配，此時需要考慮該注解的required屬性，默認是true，就會因為“必須裝配卻沒有匹配類型的對象”而拋出異常，如果顯式的設置為false，則不裝配，保持被自動裝配的屬性為null值，如果匹配類型的對象超過1個，則會嘗試byName，如果成功，則裝配，如果失敗，則拋出異常。

如果一定要說還有其它區別，可以是：

作用范圍不同：@Resource用于對字段、Setter方法進行注解，@Autowired可用于構造方法、Setter方法和字段；當同一種類型的對象有多個時（例如聲明的類型是接口，在Spring容器中有2個或多個實現類的對象），需要指定名稱，@Resource可直接配置name屬性來指定bean-name，而@Autowired需要配合@Qualifer注解，由@Qualifer注解來指定bean-name，當用于字段時，直接在字段的聲明之前使用這2個注解，當用于Setter方法時，在方法的聲明之前使用@Autowired，在方法的參數之前使用@Qualifer；

另外，還有很多關于使用@Autowired的細節問題，例如“是不是不建議使用了”、“到底應該怎么用”等等，所以，接下來主要討論這些問題。

關于“是不是不建議使用了”，這種問題的主要原因應該是最近幾年IntelliJIDEA越來越流行了，而許多版本的IntelliJIDEA對@Autowired的預判是有問題的！也就是說：IntelliJIDEA會在編碼期實時預判是否存在可以裝配的對象，如果它認為沒有，就會報錯，事實上，它的判斷并不完全準確！

例如，嘗試在Service組件中裝配一個Mapper接口類型的字段時：

（截圖來自IntelliJIDEA2020.1.4）

以上報錯就是IntelliJIDEA預判錯誤導致的，如果使用的是Eclipse就不會有這樣的問題，解決方案可以是：

在UserMapper接口上添加@Repository注解；將以上代碼中的@Autowired配置為@Autowired(required=false)，因為@Autowired默認是required=true，同時IntelliJIDEA認為沒有可裝配對象，所以報錯，顯式的配置為required=false之后，即使IntelliJIDEA認為沒有可裝配對象也不會報錯了；將以上代碼中的@Autowired改為@Resource。

再例如在使用SpringSecurity進行配置時也會有類似的問題，只不過這次它認為“存在多個匹配類型的對象”：

（截圖來自IntelliJIDEA2020.1.4）

解決以上報錯信息的方式可以是：

將聲明的UserDetailsService接口類型改為你的UserDetailsServiceImpl實現類類型，例如privateUserDetailsServerImplservice;即可；將以上代碼中的@Autowired改為@Resource。

由于許多類似問題都可以通過“將@Autowired改為@Resource”來解決，加上一些相關說法（詳見下文），且某些片面的斷章取義，導致網上還存在“使用@Resource取代@Autowired”、“以后不要再用@Autowired”的說法，而這些說法都是錯誤的，沒有任何官方（開發工具的IntelliJIDEA，或框架官方Spring）說過這樣的話！

首先，使用Spring實現自動裝配時，有3種方式：

通過構造方法注入；通過Setter注入（即與字段屬性匹配的set方法）；通過字段注入；

基本示例參見下圖：

以上圖片來自Spring官方提供的資料，可以看到最后還附了個URL，是國外網友寫的一篇主題為《whyfieldinjectionisevil》的討論文章，有興趣且有一定英語閱讀能力的朋友可以自行上網查看全文，大意是“使用字段注入時可能導致NPE”！為什么會這樣呢？假設你有如下代碼：

如果你因為某種原因直接創建對象，即通過UserServiceservice=newUserService();來創建對象，其中的userRepository屬性肯定是沒有值的，后續使用這個service對象時，只要涉及調用userRepository就會出現NPE了！

既然UserService是一個組件，為什么還會直接創建對象呢？其實這也算是一個低概率的特殊情況，在彼此不太熟悉的協同工作中可能出現，例如你和我一起開發項目，我對你寫的那部分代碼不太了解……再就是測試使用時，也可能出現直接創建對象的情況……

如果將代碼改為下面這樣：

則剛才的問題就不存在了！因為現在的構造方法是需要參數的，你不給參數，就創建不了對象！如果能創建出對象，就肯定給了參數，則userRepository肯定有值，就不會出現NPE！當然，如果你一定要傳個null進去就沒辦法了，Nozuonodiewhyyoutry？

所以，使用構造方法傳遞參數是一種強制依賴的做法，可以保證不會出現NPE，但是，如果參數太多會不會很奇怪？真的有必要把代碼寫得這么滴水不漏嗎？這個就看你自己了！首先，是IntelliJIDEA并不建議你使用字段注入：

（截圖來自IntelliJIDEA2020.1.4）

而Spring的觀點，可參見下圖：

可以看到，Spring是無所謂的，反正都能用（Springdoesn'tcare,canuseeither），當然，也列舉了使用構造方法注入和使用Setter注入的區別（雖然我在前面都是寫的字段注入，在NPE問題上，字段注入和Setter注入是一樣的）。

既然Spring都無所謂了，我們為什么還要糾結注入方式呢？還是那句話，只要你能保證不出錯，怎么都行！可能95%以上的Java從業者不是在寫大廠的大型項目，合格的程序員也不會亂寫代碼，由Setter或字段注入導致NPE的概率本來就極低，不一定需要為了“保證極端情況下也不出錯”而刻意的把代碼調整為構造方法注入，只要注意規避這個問題即可！

另外，我在上面的代碼演示中，在構造方法上加了@Autowired注解，在這里解釋一下：

如果類中只存在默認構造方法（無論是你顯式的添加的，還是根本不寫，由編譯器添加的），則無需@Autowired注解，Spring會自動調用，當然，加了也不會出錯；如果類中只存在唯一的構造方法，Spring會自動調用，且會自動從Spring容器中找對象裝配為調用構造方法的參數，這種情況也是不需要添加@Autowired注解的，加了也不會出錯；如果類中存在多個構造方法，且都沒有添加@Autowired注解時，當存在無參數構造方法時，Spring會自動調用無參數構造方法，如果你想要Spring調用另外某一個構造方法，就在那個構造方法上添加@Autowired注解；如果類中存在多個構造方法，且超過1個構造方法上都添加了@Autowired注解……你別作，你不需要知道Spring怎么處理，你只要把@Autowired刪得只有1個了，就肯定沒問題！

所以，從道理上來說，應該推薦顯式的為某1個構造方法添加@Autowired注解，哪怕是不需要添加也能用，因為這樣會保證多構造方法的情況下代碼更加直觀，增加代碼的可讀性，但是，從實際工作出發，可能就變成了“有啥好加的？這點道理都不懂還上什么班？”……大家都懶得加了，所以，又不是什么很難懂的原理，加不加就自行把握吧。

最后，再總結一下使用原則：

@Autowired和@Resource在使用時可以不糾結它們的區別，使用它們的目的就是為了裝配對象，只要能裝得上，裝的是對的，無所謂使用哪個？一定要區分選取，先保證“在同一個項目中使用同一個”，不要一個類使用@Autowired，另一個類又使用@Resource，然后，我個人建議使用@Autowired，原因嘛，很簡單，你既然用Spring框架，就用它帶的注解唄；關于@Autowired的使用方式，不怕麻煩就都使用構造方法注入，且顯式的添加@Autowired，如果怕麻煩，只要不出錯，就隨意吧。

Spring官方也考慮到了網友關于@Resource或相關注解的問題，因為沒什么需要特別解釋的了，就直接貼圖好了，大家自行查閱，以下圖片仍是來自Spring官方資料：

最后，近期因為工作的關系看了不少Spring的官方資料，包括官方的Spring學習教程，有些感慨，給我的感覺，Spring對外提倡實用主義，極少和你講理論，源碼什么的更是少得可憐，這也和面向對象的思想保持一致，人家都幫你做好了，你好好用就行了，不必關心實現細節，希望大家也能這樣！現在IT行業真的被一些大廠帶節奏了，網上各種吸引眼球的XX源碼解析、XX底層原理、XX加載過程分析、XX算法、大廠案例、大廠面試題……很多時候真的想噴一句“你咋不從操作系統開始做軟件研發呢”……真的，絕大部分Java從業者一輩子都進不了大廠，也接觸不到超過20臺以上服務器才能扛得住的項目，除非是為了應付面試，你甚至不需要知道i++和++i的區別，如果只是自己寫代碼自己用，你也不需要知道private和public的區別……如果你只想開自己的私家車，不想修車也不想造車，除了吹牛，你都不需要知道發動機的型號……多掌握實用技術，多積累解決問題的經驗，原理什么的能不管就不要管，當熟練到一定程度后，再考慮要不要深入了解原理。

好了，就這么多，如果有錯別字，大家將就一下吧（可編輯次數有限），如果有覺得不對的地方，歡迎留言討論。