一、反射的適用場景是什么？
1）.Java的反射機制在做基礎框架的時候非常有用，有一句話這么說來着：反射機制是很多Java框架的基石。而一般應用層面很少用，不過這種東西，現在很多開源框架基本都已經給你封裝好了，自己基本用不着寫。典型的除了Hibernate之外，還有Spring也用到很多反射機制。經典的就是在xml文件或者properties里面寫好了配置，然后在Java類里面解析xml或properties里面的內容，得到一個字符串，然后用反射機制，根據這個字符串獲得某個類的Class實例，這樣就可以動態配置一些東西，不用每一次都要在代碼里面去new或者做其他的事情，以后要改的話直接改配置文件，代碼維護起來就很方便了，同時有時候要適應某些需求，Java類里面不一定能直接調用另外的方法，這時候也可以通過反射機制來實現。
總的來說，自己寫的很少，具體什么時候要用那要看需求，反射機制無非就是根據一個String來得到你要的實體對象，然后調用它原來的東西。但是如果是要自己寫框架的話，那就會用得比較多了。
2）當你做一個軟件可以安裝插件的功能，你連插件的類型名稱都不知道，你怎么實例化這個對象呢？因為程序是支持插件的（第三方的），在開發的時候並不知道 。所以無法在代碼中 New出來 ，但反射可以，通過反射，動態加載程序集，然后讀出類，檢查標記之后再實例化對象，就可以獲得正確的類實例。
3）在編碼階段不知道那個類名,要在運行期從配置文件讀取類名, 這時候就沒有辦法硬編碼new ClassName(),而必須用到反射才能創建這個對象.反射的目的就是為了擴展未知的應用。比如你寫了一個程序，這個程序定義了一些接口，只要實現了這些接口的dll都可以作為插件來插入到這個程序中。那么怎么實現呢？就可以通過反射來實現。就是把dll加載進內存，然后通過反射的方式來調用dll中的方法。很多工廠模式就是使用的反射。
二、程序員在自己的業務開發中應該盡量的遠離反射
反射：在流行的庫如Spring和Hibernate中，反射自然有其用武之地。不過內省業務代碼在很多時候都不是一件好事，原因有很多，一般情況下我總是建議大家不要使用反射。
首先是代碼可讀性與工具支持。打開熟悉的IDE，尋找你的Java代碼的內部依賴，很容易吧。現在，使用反射來替換掉你的代碼然后再試一下，結果如何呢？如果通過反射來修改已經封裝好的對象狀態，那么結果將會變得更加不可控。請看看如下示例代碼：
如果這樣做就無法得到編譯期的安全保證。就像上面這個示例一樣，你會發現如果getDeclaredField()方法調用的參數輸錯了，那么只有在運行期才能發現。要知道的是，尋找運行期Bug的難度要遠遠超過編譯期的Bug。
最后還要談談代價問題。JIT對反射的優化程度是不同的，有些優化時間會更長一些，而有些甚至是無法應用優化。因此，有時反射的性能損失可以達到幾個數量級的差別。不過在典型的業務應用中，你可能不會注意到這個代價。
總結一下，我覺得在業務代碼中唯一合理(直接)使用反射的場景是通過AOP。除此之外，你最好遠離反射這一特性。
三、性能分析
反射機制是一種程序自我分析的能力。用於獲取一個類的類變量，構造函數，方法，修飾符。
優點：運行期類型的判斷，動態類加載，動態代理使用反射。
缺點：性能是一個問題，反射相當於一系列解釋操作，通知jvm要做的事情，性能比直接的java代碼要慢很多。