① java面試被問到設計模式應該怎麼回答
java 一共有23 中設計模式，例如單例模式、工廠模式、代理模式、適配器模式等，面試被問到你就說出幾個對應的設計模式，不能只知道名字啊，得了解這些設計模式是原理。如果你記憶力好都記下來也可以
② java中幾種常見的設計模式
一共23種設計模式！
按照目的來分，設計模式可以分為創建型模式、結構型模式和行為型模式。
創建型模式用來處理對象的創建過程；結構型模式用來處理類或者對象的組合；行為型模式用來對類或對象怎樣交互和怎樣分配職責進行描述。
創建型模式用來處理對象的創建過程，主要包含以下5種設計模式：
工廠方法模式（Factory Method Pattern）
抽象工廠模式（Abstract Factory Pattern）
建造者模式（Builder Pattern）
原型模式（Prototype Pattern）
單例模式（Singleton Pattern）
結構型模式用來處理類或者對象的組合，主要包含以下7種設計模式：
適配器模式（Adapter Pattern）
橋接模式（Bridge Pattern）
組合模式（Composite Pattern）
裝飾者模式（Decorator Pattern）
外觀模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
行為型模式用來對類或對象怎樣交互和怎樣分配職責進行描述，主要包含以下11種設計模式：
責任鏈模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
解釋器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
備忘錄模式（Memento Pattern）
觀察者模式（Observer Pattern）
狀態模式（State Pattern）
策略模式（Strategy Pattern）
模板方法模式（Template Method Pattern）
訪問者模式（Visitor Pattern）
推薦你一本好書：《軟體秘笈：設計模式那點事》，裡面講解的23中設計模式例子很生動，容易理解，還有JDK中設計模式應用情況，看了收獲挺大的！網路裡面搜「設計模式」，第一條中設計模式網路中就有首推該圖書，瀏覽量在20幾萬以上的，不會錯的。好東西大家一起分享！
祝你早日學會設計模式！
③ java編碼中用設計模式與不用設計模式有什麼區別為什麼那些面試官老是喜歡問設計模式
使用了設計模式之後代碼看起來更結構化，在很小的項目中橘裂看不出來，但是如果是一個大項目的話，凌亂的代碼會讓人頭痛
為什麼面試官老是喜歡問設計模式：
因為寫代碼久了基本功都會了之後就需要更進一步的技能：寫出更結構化的代碼
設計模式是面試時候的一個常問的問題，面試官也是人，自己也要想面試別人的問題啊，想了也頭痛圓畢閉，既然這個常問就拿來問了
說實在話，java面試問設計模式已數銀經是一個好多年的老傳統了，但是現在再審視一下這本成書較早的書，其實裡面很多的模式已經過時，有些並不適用於java，我感覺總是問設計模式也沒啥意思
所以很大的原因也是面試官懶，不想創新的去想面試的問題，直接問這種傳統問題省事
④ java面試中主要掌握的設計模式有哪些
java面試
設計模式主要分三個類型:創建型、結構型和行為型。
其中創建型有：
一、Singleton，單例模式：保證一個類只有一個實例，並提供一個訪問它的全局訪問點
二、Abstract Factory，抽象工廠：提供一個創建一系列相關或相互依賴對象的介面，而無須指定它們的具體類。
三、Factory Method，工廠方法：定義一個用於創建對象的介面，讓子類決定實例化哪一個類，Factory Method使一個類的實例化延遲到了子類。
四、Builder，建造模式：將一個復雜對象的構建與他的表示相分離，使得同樣的構建過程可以創建不同的表示。
五、Prototype，原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型來創建新的對象。
行為型有：
六、Iterator，迭代器模式：提供一個方法順序訪問一個聚合對象的各個元素，而又不需要暴露該對象的內部表示。
七、Observer，觀察者模式：定義對象間一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知自動更新。
八、Template Method，模板方法：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中，TemplateMethod使得子類可以不改變一個演算法的結構即可以重定義該演算法得某些特定步驟。
九、Command，命令模式：將一個請求封裝為一個對象，從而使你可以用不同的請求對客戶進行參數化，對請求排隊和記錄請求日誌，以及支持可撤銷的操作。
十、State，狀態模式：允許對象在其內部狀態改變時改變他的行為。對象看起來似乎改變了他的類。
十一、Strategy，策略模式：定義一系列的演算法，把他們一個個封裝起來，並使他們可以互相替換，本模式使得演算法可以獨立於使用它們的客戶。
十二、China of Responsibility，職責鏈模式：使多個對象都有機會處理請求，從而避免請求的送發者和接收者之間的
開發模式:
JAVA中的開發模式:
MVC是一個很常用的程序開發設計模式，M-Model（模型）
⑤ java面試問獨立解決過哪些難題
您好，我曾獨立解決過多種Java面試難題，比如：
1. Java集合：我曾解決過關於Java集合的各種問題，比如如何侍凳使用HashMap和HashSet，如何使用ArrayList和LinkedList，以及如何使用TreeSet和TreeMap。
2. Java多線程：我曾解決過關於Java多線程的各種問題，比如如何使用Thread和Runnable，如何使用synchronized和volatile，以及如何使用wait/notify和CountDownLatch。
3. Java設計模式：我曾解決過關於Java設計模式的各種問題，比如如何仿談鍵使用單例模式，如何使用工廠模式，以及如何使用觀察者模式。
4. Java數據結構：我曾解決過關於Java數據結構備巧的各種問題，比如如何使用棧和隊列，如何使用堆和優先隊列，以及如何使用二叉樹和圖。
5. Java演算法：我曾解決過關於Java演算法的各種問題，比如如何使用排序演算法，如何使用搜索演算法，以及如何使用動態規劃演算法。
⑥ 程序員小白如何通過Java面試
1、了解業內招聘要求：多看幾家同類崗位的技術要求，大概就知道用人單位的需求了
2、多找找面試常見技術題：不同企業的面試題各種不同，多去找找，多背背
3、簡歷設計：這個就是要注意在簡歷中體現自己的項目經驗、技術水平
4、面試現場反應：注意自己的著裝、語言表達、技術表達
以上都是在你有專業技術的前提下進行的，如果專業技術就是小白，還是先提升專業技術吧
⑦ Java常見設計模式
正配漏州常情況下一個設計模式描述了一個被證實可行的方案。這些方案非常普遍，是具有完整定義的最常用的模式。IT培訓認為一般模式有4個基本要素：模式名稱(patternname)、問題(problem)、解決方案(solution)、效果(consequences)。常見的Java設計模式搜凱有以下10種：
1、橋梁模式(Bridge)：將抽象部分與它的實培蔽現部分分離，使它們都可以獨立地變化。
2、合成模式(Composite)：將對象組合成樹形結構以表示"部分-整體"的層次結構。它使得客戶對單個對象和復合對象的使用具有一致性。
3、抽象工廠模式(AbstractFactory)：提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。
4、裝飾模式(Decorator)：動態地給一個對象添加一些額外的職責。就擴展功能而言，它能生成子類的方式更為靈活。
5、適配器模式(Adapter)：將一個類的介面轉換成客戶希望的另外一個介面。適配器模式使得原本由於介面或類不兼容而不能一起工作的類可以一起工作。
6、責任鏈模式(ChainofResponsibility)：為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個對象處理它。
7、工廠方法(FactoryMethod)：定義一個用於創建對象的介面，讓子類決定將哪一個類實例化。FactoryMethod使一個類的實例化延遲到其子類。
8、建造模式(Builder)：將一個復雜對象的構建與它的表示分離，使同樣的構建過程可以創建不同的表示。
9、門面模式(Facade)：為子系統中的一組介面提供一個一致的界面，門面模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。
10、命令模式(Command)：將一個請求封裝為一個對象，從而可用不同的請求對客戶進行參數化;對請求排隊或記錄請求日誌，以及支持可取消的操作。
⑧ Java編程開發常用的幾種設計模式
隨著我們對Java編程開發語言的掌握，對於不同場景下使用哪種設計模式會有更清晰的判斷。下面IT培訓就一起來了解一下，JavaScript編程中的幾種常見設計模式都有哪些類型。
設計原則
單一職責原則(SRP)
一個對象或方法只做一件事情。如果一個方法承擔了過多的職責，那麼在需求的變遷過程中，需要改寫這個方法的可能性就越大。
應該把對象或方法劃分成較小的粒度
少知識原則(LKP)
一個軟體實體應當盡可能少地與其他實體發生相互作用
應當盡量減少對象之間的交互。如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不要發生直接的相互聯系，可以轉交給三方進行處理
開放-封閉原則(OCP)
軟體實體(類、模塊、函數)等應該是可以擴展的，但是不可修改
當需要改變一個程序的功能或者給這個程序增加新功能的時候，可以使用增加代碼的方式，盡量避免改動程序賀陵的源代碼，防止影響原系統的穩定
什麼是設計模式
作者的這個說明解釋得挺好
假設有禪賣戚一個空房間，我們要日復一日地往裡面放一些東西。簡單的辦法當然是把這些東西直接扔進去，但是時間久了，就會發現很難從這個房子里找到自己想要的東西，要配亂調整某幾樣東西的位置也不容易。所以在房間里做一些櫃子也許是個更好的選擇，雖然櫃子會增加我們的成本，但它可以在維護階段為我們帶來好處。使用這些櫃子存放東西的規則，或許就是一種模式
⑨ JAVA面試題---設計一個類，該類只能生成一個實例
單實例Singleton設計模式可能是被討論和使用的最廣泛的一個設計模式了，這可能也是面試中問得最多的一個設計模式了。這個設計模式主要目的是想在整個系統中只能出現一個類的實例。這樣做當然是有必然的，比如你的軟體的全局配置信息，或者是一個Factory，或是一個主控類，等等。你希望這個類在整個系統中只能出現一個實例。當然，作為一個技術負責人的你，你當然有權利通過使用非技術的手段來達到你的目的。比如：你在團隊內部明文規定，「XX類只能有一個全局實例，如果某人使用兩次以上，那麼該人將被處於2000元的罰款！」（呵呵），你當然有權這么做。但是如果你的設計的是東西是一個類庫，或是一個需要提供給用戶使用的API，恐怕你的這項規定將會失效。因為，你無權要求別人會那麼做。所以，這就是為什麼，我們希望通過使用技術的手段來達成這樣一個目的的原因。
本文會帶著你深入整個Singleton的世界，當然，我會放棄使用C++語言而改用Java語言，因為使用Java這個語言可能更容易讓我說明一些事情。
Singleton的教學版本
這里，我將直接給出一個Singleton的簡單實現，因為我相信你已經有這方面的一些基礎了。我們姑且把這具版本叫做1.0版
// version 1.0
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
singleton= new Singleton();
}
return singleton;
}
}
在上面的實例中，我想說明下面幾個Singleton的特點：（下面這些東西可能是盡人皆知的，沒有什麼新鮮的）
私有（private）的構造函數，表明這個類是不可能形成實例了。這主要是怕這個類會有多個實例。
即然這個類是不可能形成實例，那麼，我們需要一個靜態的方式讓其形成實例：getInstance（）。注意這個方法是在new自己，因為其可以訪問私有的構造函數，所以他是可以保證實例被創建出來的。
在getInstance（）中，先做判斷是否已形成實例，如果已形成則直接返回，否則創建實例。
所形成的實例保存在自己類中的私有成員中。
我們取實例時，只需要使用Singleton.getInstance（）就行了。
當然，如果你覺得知道了上面這些事情後就學成了，那我給你當頭棒喝一下了，事情遠遠沒有那麼簡單。
Singleton的實際版本
上面的這個程序存在比較嚴重的問題，因為是全局性的實例，所以，在多線程情況下，所有的全局共享的東西都會變得非常的危險，這個也一樣，在多線程情況下，如果多個線程同時調用getInstance（）的話，那麼，可能會有多個進程同時通過 （singleton== null）的條件檢查，於是，多個實例就創建出來，並且很可能造成內存泄露問題。嗯，熟悉多線程的你一定會說——「我們需要線程互斥或同步」，沒錯，我們需要這個事情，於是我們的Singleton升級成1.1版，如下所示：
// version 1.1
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
synchronized (Singleton.class) {
singleton= new Singleton();
}
}
return singleton;
}
}
嗯，使用了Java的synchronized方法，看起來不錯哦。應該沒有問題了吧？！錯！這還是有問題！為什麼呢？前面已經說過，如果有多個線程同時通過（singleton== null）的條件檢查（因為他們並行運行），雖然我們的synchronized方法會幫助我們同步所有的線程，讓我們並行線程變成串列的一個一個去 new，那不還是一樣的嗎？同樣會出現很多實例。嗯，確實如此！看來，還得把那個判斷（singleton== null）條件也同步起來。於是，我們的Singleton再次升級成1.2版本，如下所示： // version 1.2
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
synchronized (Singleton.class)
{
if (singleton== null)
{
singleton= new Singleton();
}
}
return singleton;
}
}
不錯不錯，看似很不錯了。在多線程下應該沒有什麼問題了，不是嗎？的確是這樣的，1.2版的Singleton在多線程下的確沒有問題了，因為我們同步了所有的線程。只不過嘛……，什麼？！還不行？！是的，還是有點小問題，我們本來只是想讓new這個操作並行就可以了，現在，只要是進入 getInstance（）的線程都得同步啊，注意，創建對象的動作只有一次，後面的動作全是讀取那個成員變數，這些讀取的動作不需要線程同步啊。這樣的作法感覺非常極端啊，為了一個初始化的創建動作，居然讓我們達上了所有的讀操作，嚴重影響後續的性能啊！
還得改！嗯，看來，在線程同步前還得加一個（singleton== null）的條件判斷，如果對象已經創建了，那麼就不需要線程的同步了。OK，下面是1.3版的Singleton.
// version 1.3
public class Singleton
{
private static final Singleton singleton = null;
private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
synchronized (Singleton.class)
{
if (singleton== null)
{
singleton= new Singleton();
}
}
}
return singleton;
}
}
感覺代碼開始變得有點羅嗦和復雜了，不過，這可能是最不錯的一個版本了，這個版本又叫「雙重檢查」Double-Check.下面是說明：
第一個條件是說，如果實例創建了，那就不需要同步了，直接返回就好了。
不然，我們就開始同步線程。
第二個條件是說，如果被同步的線程中，有一個線程創建了對象，那麼別的線程就不用再創建了。
相當不錯啊，幹得非常漂亮！請大家為我們的1.3版起立鼓掌！
Singleton的其它問題
怎麼？還有問題？！當然還有，請記住下面這條規則——「無論你的代碼寫得有多好，其只能在特定的范圍內工作，超出這個范圍就要出Bug了」，這是「陳式第一定理」，呵呵。你能想一想還有什麼情況會讓這個我們上面的代碼出問題嗎？
在C++下，我不是很好舉例，但是在Java的環境下，嘿嘿，還是讓我們來看看下面的一些反例和一些別的事情的討論（當然，有些反例可能屬於鑽牛角尖，可能有點學院派，不過也不排除其實際可能性，就算是提個醒吧）：
其一、Class Loader.不知道你對Java的Class Loader熟悉嗎？「類裝載器」？！C++可沒有這個東西啊。這是Java動態性的核心。顧名思義，類裝載器是用來把類（class）裝載進JVM的。 JVM規范定義了兩種類型的類裝載器：啟動內裝載器（bootstrap）和用戶自定義裝載器（user-defined class loader）。在一個JVM中可能存在多個ClassLoader，每個ClassLoader擁有自己的NameSpace.一個ClassLoader只能擁有一個 class對象類型的實例，但是不同的ClassLoader可能擁有相同的class對象實例，這時可能產生致命的問題。如ClassLoaderA，裝載了類A的類型實例A1，而ClassLoaderB，也裝載了類A的對象實例A2.邏輯上講A1=A2，但是由於A1和A2來自於不同的 ClassLoader，它們實際上是完全不同的，如果A中定義了一個靜態變數c，則c在不同的ClassLoader中的值是不同的。
於是，如果咱們的Singleton 1.3版本如果面對著多個Class Loader會怎麼樣？呵呵，多個實例同樣會被多個Class Loader創建出來，當然，這個有點牽強，不過他確實存在。難道我們還要整出個1.4版嗎？可是，我們怎麼可能在我的Singleton類中操作 Class Loader啊？是的，你根本不可能。在這種情況下，你能做的只有是——「保證多個Class Loader不會裝載同一個Singleton」。
其二、序例化。如果我們的這個Singleton類是一個關於我們程序配置信息的類。我們需要它有序列化的功能，那麼，當反序列化的時候，我們將無法控制別人不多次反序列化。不過，我們可以利用一下Serializable介面的readResolve（）方法，比如：
public class Singleton implements Serializable
{
......
......
protected Object readResolve()
{
return getInstance();
}
}
其三、多個Java虛擬機。如果我們的程序運行在多個Java的虛擬機中。什麼？多個虛擬機？這是一種什麼樣的情況啊。嗯，這種情況是有點極端，不過還是可能出現，比如EJB或RMI之流的東西。要在這種環境下避免多實例，看來只能通過良好的設計或非技術來解決了。
其四，volatile變數。關於volatile這個關鍵字所聲明的變數可以被看作是一種 「程度較輕的同步synchronized」；與 synchronized 塊相比，volatile 變數所需的編碼較少，並且運行時開銷也較少，但是它所能實現的功能也僅是synchronized的一部分。當然，如前面所述，我們需要的 Singleton只是在創建的時候線程同步，而後面的讀取則不需要同步。所以，volatile變數並不能幫助我們即能解決問題，又有好的性能。而且，這種變數只能在JDK 1.5+版後才能使用。
其五、關於繼承。是的，繼承於Singleton後的子類也有可能造成多實例的問題。不過，因為我們早把Singleton的構造函數聲明成了私有的，所以也就杜絕了繼承這種事情。
其六，關於代碼重用。也話我們的系統中有很多個類需要用到這個模式，如果我們在每一個類都中有這樣的代碼，那麼就顯得有點傻了。那麼，我們是否可以使用一種方法，把這具模式抽象出去？在C++下這是很容易的，因為有模板和友元，還支持棧上分配內存，所以比較容易一些（程序如下所示），Java下可能比較復雜一些，聰明的你知道怎麼做嗎？
template<CLASS T> class Singleton
{
public:
static T& Instance()
{
static T theSingleInstance; //假設T有一個protected默認構造函數
return theSingleInstance;
}
};
class OnlyOne : public Singleton<ONLYONE>
{
friend class Singleton<ONLYONE>;
int example_data;
public:
int GetExampleData() const {return example_data;}
protected:
OnlyOne(): example_data(42) {} // 默認構造函數
OnlyOne(OnlyOne&) {}
};
int main( )
{
cout << OnlyOne::Instance().GetExampleData()<< endl;
return 0;