① 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;