16:53 提问
Android 使用单例模式创建数据库中的问题
如图调用getInstance来获取实例，行参是Context类，此处填了this。如果数据库还没有创建，就会自动调用私有化的构造方法，我的问题是，构造方法处的Context表示什么？实在不理解啊。。。
按赞数排序
先说一点， 单例模式里面 CoolWeatherDB应该是private的, 否则外面都能直接访问了
context就是上下文，包含了下页面跳转的参数什么的
你传的什么就是什么，多多数可能是activity，或者其他你使用的上下文对象
public static void init(Context context){//在Application中初始化就行了，或者在主界面的activity中也行。
if(coolWeatherDB==null){
coolWeatherDB = new CoolWeatherDB(context)
public static CoolWeatherDB getInstance(){
return coolWeatherDB
context就是上下文，所以要确保context已初始化,我们可以把实例化DBManager的步骤放在Activity的onCreate里
13.public class SqliteActivity extends Activity {
/** Called when the activity is first created. */
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
DBHelper helper = new DBHelper(SqliteActivity.this,"sqlite.db");
Log.d("Avin","this is onCreate in SqliteActivity...the helper is --&"+helper);
SQLiteDatabase sdb = helper.getReadableDatabase();
Log.d("Avin","this is onCreate in SqliteActivity...the sdb is --&"+sdb);
sdb = helper.getWritableDatabase();
//如果不指定主键 会正常运行吗
//试试证明，会！
//批量插入
String[] cands = {"a","b","c","d"};
String[] keys = {"1","2","3","4"};
for(int i=0; i&cands. i++){
ContentValues cv = new ContentValues();
cv.put("flt_cand", cands[i]);
cv.put("flt_key", keys[i]);
sdb.insert("floats", null, cv);
Log.d("Avin","insert...");
sdb.close();
sdb = helper.getReadableDatabase();
Cursor cur = sdb.query("floats", new String[]{"flt_cand"}, "flt_key=?", new String[]{"4"}, null, null, null);
while(cur.moveToNext()){
String rst = cur.getString(cur.getColumnIndex("flt_cand"));
Log.d("Avin", rst);
基本上cur.moveToNext() 看能否解決你的問題
说上下文的，麻烦解释清楚些。我也知道是上下文
Context 就是Context对象。 Application Activity 都继承 类
Context 。[
android.content.Context ]
操作apk资源和数据库，都需要 Context 。
准确详细的回答，更有利于被提问者采纳，从而获得C币。复制、灌水、广告等回答会被删除，是时候展现真正的技术了！
其他相关推荐896 次阅读
标签：至少1个，最多5个
单例模式是应用最广的模式之一，在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个全局对象，这样有利于我们协调系统整体的行为。如在一个应用中，应该只有一个ImageLoader实例，这个ImageLoader中又含有线程池、缓存系统、网络请求等，很消耗资源。因此不应该让它构造多个实例。这样不能自由构造对象的情况，就是单例模式的使用场景。
确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
确保某个类有且只要一个对象的场景，避免产生多个对象消耗过多的资源，或者某种类型的对象只应该有且只有一个。例如，创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源，这时就要考虑使用单例模式。
单例模式的UML类图如下：
角色介绍：
Client：高层客户端
Singleton：单例类
实现单例模式主要有以下几个关键点：
构造函数不对外开放，一般为private；
通过一个静态方法或者枚举返回单例类对象；
确保单例类的对象有且只有一个，尤其是在多线程环境下；
确保单例类对象在反序列化时不会重新构建对象；
单例模式中实现比较困难的是在多线程环境下构造单例类的对象有且只有一个。
单例模式在设计模式中是结构比较简单的，只有一个单例类，没有其他层次结构和抽象。该模式需要确保该类只能生成一个对象，通常是该类需要消耗较多的资源或者没有对个实例的情况。例如一个公司只有一个CEO、一个应用只有一个Application对象等。
下面以公司里的CEO为例来简单演示一下，一个公司可以有多个VP、无数个员工，但只有一个CEO，代码如下：
* 普通员工
public class Staff {
public void work() {
public class VP extends Staff {
public void work() {
// 管理下面的经理
//CEO，饿汉式单例
public class CEO extends Staff {
private static final CEO mCEO = new CEO();
private CEO() {
//公有的静态函数，对外暴露获取单例对象的接口
public static CEO getCeo() {
return mCEO;
public void work() {
public class Company {
private List&Staff& mStaffs = new ArrayList&Staff&();
public void addStaff(Staff staff) {
mStaffs.add(staff);
public void showStaffs() {
for(Staff staff : mStaffs) {
System.out.println("Obj: " + staff.toString());
public static void main(String[] args) {
// TODO Auto-generated method stub
Company company = new Company();
//CEO对象只能通过getCeo获取
Staff ceo1 = CEO.getCeo();
Staff ceo2 = CEO.getCeo();
company.addStaff(ceo1);
company.addStaff(ceo2);
Staff vp1 = new VP();
Staff vp2 = new VP();
company.addStaff(vp1);
company.addStaff(vp2);
Staff staff1 = new Staff();
Staff staff2 = new Staff();
company.addStaff(staff1);
company.addStaff(staff2);
company.showStaffs();
运行输出结果如下：
Obj: com.liuguoquan.design.single.CEO@15db9742
Obj: com.liuguoquan.design.single.CEO@15db9742
Obj: com.liuguoquan.design.single.VP@6d06d69c
Obj: com.liuguoquan.design.single.VP@
Obj: com.liuguoquan.design.single.Staff@4e25154f
Obj: com.liuguoquan.design.single.Staff@70dea4e
从上面代码可以看出，CEO类不能通过new的形式构造函数，只能通过CEO.getCeo()方法来获取，而这个CEO对象是静态对象，并且在声明的时候就已经初始化，这就保证类CEO对象的唯一性。
从输出结果中可以看出，CEO两次输出的CEO对象的地址都一样，说明是同一个CEO对象；而VP、Staff等类型的对象都是不同的。
饿汉式模式是在声明静态对象时就已经初始化，这种方式简单粗暴，如果单例对象初始化非常快，而且占用内存小的时候这种方式是比较适合的，可以直接在应用启动时加载初始化。实现如下：
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton() {
public static Singleton getInstance() {
懒汉模式是声明一个静态对象，并且在用户第一次调用getInstance时进行初始化。
public class Singleton {
private static Singleton instance =
private Singleton() {
public static Singleton getInstance() {
synchronized(Singleton.class) {
if (instance == null) {
instance = new Singleton();
getInstance方法中添加了Synchronized关键字，也就是同步类synchronized关键字包含的代码块，这就是上面所说的在多线程中保证单例对象唯一性的手段。但是仍存在一个问题，即使instance已经初始化，每次调用getInstance方法都会进行同步，这样会消耗不必要的资源，这也是懒汉式存在的最大问题。
懒汉单例模式的优点是只有在使用时才会被实例化，在一定程度上节约了资源，缺点是第一次加载时需要及时进行实例化，反应稍慢，最大问题是每次调用geInstance都进行同步，造成不必要的同步开销，这样模式一般不建议使用。
Double CheckLock(双重校验锁)
DCL方式的优点是既能够在需要时才初始化单例，又能够保证线程的安全，且单例对象初始化后调用getInstance不获取同步锁。
public class Singleton {
//private static volatile Singleton instance =
private static Singleton instance =
private Singleton() {
public static Singleton getInstance() {
//如果已经初始化，不需要每次获取同步锁
if(instance == null) {
synchronized(Singleton.class) {
if (instance == null) {
instance = new Singleton();
可以看到getInstance方法对instance进行了两次判空：第一层判断主要是为了避免不必要的同步，第二层判断主要则是为了在null的情况下创建实例。下面，我们来分析一下：
假设线程A执行到instance=new Singleton()语句，这里看起来是一句代码，但实际上它并不是一个原子操作，这局代码最终会被编译成多条汇编指令，它大致做了3件事情：
给Singleton的实例分配内存
调用Singleton()的 构造函数，初始化字段成员
将instance对象执行分配的内存空间（此时instance就不是null了）
但是，由于Java编译器运行处理器乱序执行，以及jdk1.5之前Java内存模型中Cache、寄存器到主内存会写顺序的规定，上面的第二和第三的顺序是无法保证的。也就是说，执行顺序可能是1-2-3也可能是1-3-2.如果是后者，并且在3执行完毕、2未执行之前，被切换到线程B上，这时候instance因为已经在线程A内执行3了，instance已经是非null，所有线程B直接取走instance，再使用时就会出错，这就是DCL失效问题，而且这种难以跟踪难以重现的问题很可能会隐藏很久。
在jdk1.5之后，官方已经注意到这种问题，调整了JMM、具体化了volatile关键字，因此，如果是1.5或之后的版本，只需要将instance的定义改成private static volatile Singleton instance =就可以保证instance对象每次都是从主内存中读取，就可以使用DCL的写法来完成单例模式。当然，volatile多少会影响到性能，但考虑到程序的正确性，牺牲这点性能还是值得的。
DCL的优点：资源利用率高，第一次执行getInstance时单例对象才会被实例化，效率高。
缺点：第一次加载稍慢，也由于Java内存模型的原因偶尔会失败。在高并发的环境下也有一定的缺陷，虽然概率发生很小。
DCL模式是使用最多的单例实现模式，它能够在需要时才实例化单例对象，并且能够在绝大多数场景下保证单例对象的唯一性，除非你的代码在并发场景比较复杂或者低于jdk1.6版本下使用，否则这种方式一般能够满足需求。
静态内部类单例模式
在《Java并发编程实战》中谈到不赞成使用DCL的优化方式，而建议使用如下代码替代：
public class Singleton {
private Singleton() {}
public static Singleton getInstance() {
return SingletonHolder.
//静态内部类
private static class SingletonHolder {
private static final Singleton instance = new Singleton();
当第一次加载Singleton类时并不会初始化instance，只有第一次调用Singleton的getInstance方法时才会导致instance被初始化。因此，第一次调用getInstance方法会导致虚拟机加载SingletonHolder类，这种方式不仅能够确保线程安全，也能够保证单例对象的唯一性，同时也延迟了单例的实例化，所以这是推荐使用的单例模式实现方式。
public enum Singleton {
//定义一个枚举的元素，它就是Singleton的一个实例
public void doSomething() {
public static void main(String[] args){
Singleton singleton = Singleton.
singleton.doSomething();
写法简单是枚举单例最大的优点，枚举在Java中与普通的类是一样的，不仅能够有字段，还能够有自己的方法。最重要的是默认枚举实例的创建时线程安全的，并且在任何情况下它都是一个单例。
为什么这么说呢？在上述的几种单例模式实现中，在一个情况下它们会出现重新创建对象的情况，那就是反序列化。
通过序列化可以将一个单例的实例对象写到磁盘，然后再读回来，从而有效地获得一个实例。即使构造函数时私有的，反序列化时依然可以通过特殊的途径去创建类的一个新的实例，相当于调用该类的构造函数。反序列化操作提供一个很特别的钩子函数，类中具有一个私有的、被实例化的方法readResolve()，这个方法可以让开发人员控制对象的反序列化。例如，上述几个实例中如果要杜绝单例对象在被反序列化时重新生成对象，那么必须加入如下方法：
private Object readResolve() throws ObjectStreamException {
也就是在readResolve方法中将instance对象返回，而不是默认的重新生成一个新的对象。而对于枚举并不存在这样的问题，因为即使反序列化它也不会重新生成新的实例。
容器管理单例
public class SingletonManager {
private static Map&String,Object& objMap = new HashMap&String,Object&();
public static void registerService(String key,Object instance) {
if (!objMap.containsKey(key)) {
objMap.put(key);
public static getInstance(String key) {
return objMap.get(key);
在程序的初始，将多种单例类注入到一个统一的管理类中，在使用根据key获取对应类型的对象，这种方式使得我们可以管理很多类型的单例，并且在使用它们的时候可以通过统一的接口进行获取操作操作，降低用户的使用成本，也对用户隐藏了具体实现，降低了耦合度。
单例模式是运用频率很高的模式，但是，由于在客户端通常没有高并发的情况，因此，选择哪种实现方式并不会有太大的影响。即便如此，出于效率考虑，推荐使用双重校验锁和静态内部类单例模式。
由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁创建、销毁时，而且创建或者销毁时性能又无法优化，单例模式的优势就非常明显。
由于单例模式只生成一个实例，所以，减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后用永驻内存的方式解决。
单例模式可以避免对资源的多重占用，例如一个写文件操作，由于只有一个实例存在内存中，避免对同一个资源文件的同时写操作。
单例模式可以在系统设置全局访问点，优化和共享资源访问，例如，可以设计一个单例类，负责所有数据表的映射处理。
单例模式一般没有接口，扩展很困难，若要扩展，除了修改代码基本没有第二种途径可以实现。
在Android中，单例对象如果持有Context，那么很容易引发内存泄露，此时需要注意传给单例对象的Context最好是Application Context。
0 收藏&&|&&1
你可能感兴趣的文章
你可能感兴趣的文章
分享到微博？
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。扫一扫体验手机阅读
Android和设计模式：单例模式
&&& 单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。Android SDK很庞大。和我们现实中的大组织类似，其中很多的功能靠各种Manager完成的。比如WindowManager、PowerManager、SensorManager、ActivityManager、StorageManager、ServiceManager等等。每个经理都是一个单例。其中的ServiceManager实现示例如下：
public final class ServiceManager {
&&& private static final String TAG = "ServiceManager";
&&& private static IServiceManager sServiceM
&&& private static IServiceManager getIServiceManager() {
&&&&&&& if (sServiceManager != null) {
&&&&&&&&&&& return sServiceM
&&&&&&& // Find the service manager
&&&&&&& sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
&&&&&&& return sServiceM
这样既可以实现全局访问，也可以确保有效资源的充分使用。
<span type="1" blog_id="649068" userid='
241篇文章，125W+人气，0粉丝
<span type="1" blog_id="649068" userid='单例模式在android中使用
单例模式（Singleton）
单例模式是对象的创建模式，单例模式能够确保某个类只有一个单一的实例对象存在，同时能够自行实例化并将单一的实例提供给外界调用的特点，其在实际项目开发中经常被用到。
结合上面的模式结构说明图，我们可以看到单例模式有几个显著的特点，具体如下所示：
A、单例类(Singleton)只能有一个唯一的实例存在。
B、单例类必须有能够自行创建自己的实例对象的能力。
C、单例类必须能够给外界其他对象提供这个实例。
另外，对于单例模式从产生到现在，也已经有了几种形式，下面我们就介绍几种常用到的形式（以代码的形式说明）：
第一种形式：
* 单例模式---形式1
public class SingletonA {
private static final SingletonA instance = new SingletonA();
/* 私有构造子*/
private SingletonA() {
/* 供外部调用的实例方法*/
public static SingletonA getInstance(){
return instance;
第二种形式：
* 单例模式---形式2
public class SingletonB {
private static SingletonB instance = null;
/* 私有构造子*/
private SingletonB() {
/* 供外部调用的实例方法*/
public static SingletonB getInstance() {
if(null == instance) {
instance = new SingletonB();
return instance;
第三种形式：
* 单例模式---形式3
public class SingletonC {
private static SingletonC instance = null;
/* 私有构造子*/
private SingletonC() {
/* 供外界调用的实例方法 这里用到了同步*/
public static synchronized SingletonC getInstance() {
if(null == instance) {
instance =
new SingletonC();
return instance;
当然，在这里我只列出了比较常见到的几种形式的单例，下面来具体的分析下他们之间的联系和区别，并在最后举个实际的例子来使用单例模式。具体如下所示：
对于形式1的单例模式的特点就是在单例类自己被加载的时候就将自己实例化了。但从资源的利用率角度看的话，这种方式的实现会差一点；而第二种形式的单例模式是对第一种形式的小缺点做了优化，即在加载器加载单例类时不选择创建实例对象，只有在真正需要这个单例的时候才去创建唯一的实例；如果从时间和反应的速度看的话，那么形式1的单例要比形式2的要快些。对于形式3的单例，由于它使用了同步的机制，这样势必会降低它的性能，有利也有弊，它能够很好的在异步线程中保证实例的唯一性。
总的来说，形式1和形式2更符合机制，就我个人习惯于第二种形式的单例模式。下面具体举个例子来说明单例的使用，当然我使用自己习惯的单例模式形式。例子是这样的，在实际项目当中，我么会经常的要获取移动设备的屏幕宽和高，那么为了便于管理和统一，我们一般选择将获取宽和高的方法封装在一个单一的类中，同时为了避免重复的创建这个类，我们选择单例模式来实现。我的代码如下：
单例模式：
/* 单例类*/
public class PhoneUtil {
private static PhoneUtil instance = null;
private static Context context = null;
/* 私有的构造子*/
private PhoneUtil(Context ctx) {
/* 供外部调用的实例化方法 保证创建唯一的实例对象*/
public static PhoneUtil getInstance(Contextctx) {
if(null == instance) {
instance =
new PhoneUtil(ctx);
return instance;
/* 获得屏幕的宽度*/
public int getScreenWidth() {
Display display = ((WindowManager)
context.getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay();
return display.getWidth();
/* 获得屏幕的高度*/
public int getScreenHeight() {
Display display = ((WindowManager)
context.getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay();
return display.getHeight();
前端调用：
public class SingletonActivity extends Activity {
private static String TAG = SingletonA
protected void onCreate(BundlesavedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_singleton);
int screenWidth = PhoneUtil.getInstance(this).getScreenWidth();
log(the screen width: + screenWidth);
int screenHeight = PhoneUtil.getInstance(this).getScreenHeight();
log(the screen height: + screenHeight);
private void log(String log) {
Log.d(TAG, log);
代码的运行效果：
从上面的图，我的手机的屏幕宽和高分别为320和480，看来分辨率和屏幕小的可怜了！
好了，到这里我们基本分析和使用了常用的单例模式。Java设计模式之单例模式及在Android中的重要使用
　　之前在开发中老用到一些设计模式可是呢又不是很懂，于是狠下心来琢磨一番。下面是我琢磨后总结的，希望对您有用。如果发现了问题，请帮忙指正。
一、单例模式是什么？
　　单例模式最初的定义出现于《设计模式》：“保证一个类仅有一个实例，并提供一个访问它的全局访问点。”
　　Java中单例模式定义；“一个类有且仅有一个实例，并且自行实例化向整个系统提供该实例。”
二、为什么用单例模式？
　　对于系统中的某些类来说，只有一个实例很重要。例如，一个系统中可以存在多个打印任务，但是只能有一个正在工作的任务；一个系统只有有一个窗口管理器或文件系统；一个系统只能有一个计时工具或ID生成器。如在Windows OS 中就只能打开一个任务管理器。如果不使用机制对窗口对象进行唯一化，将弹出多个窗口，如果这些窗口显示的内容完全一致，则重复对象，浪费内存资源；如果这些窗口显示的内容不一致，则意味着某一瞬间系统有多个状态，与实际不符，也会为用户带来误解，不知道哪一个才是真实的状态。因此有时确保系统中某个对象的唯一性即一个类只能有一个实例是非常重要的。
　　如何保证一个类只有一个实例并且这个实例易于被访问呢？定义一个全局变量可以确保对象随时都可以被访问，但不能防止我们实例化多个对象。一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。
三、单例模式特点
单例模式特点有三个
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给其他对象（整个系统）提供这一实例。
　从具体实现角度分析，一是单例模式的类只提供私有的(private)构造函数，二是类定义中含有一个该类的静态私有(private static)对象，三是该类提供了一个静态的（static）公有的(public)函数用于创建或获取它本身的静态私有对象。
四、Java中几种常见单例模式写法
　　通过上面的介绍你是不是对单例模式有了一个总的概念？没有，那接下来继续给你们放大招。
　　基于单例模式特点，单例对象通常作为程序中存放配置信息的载体（想想Android中的Application经常在里面做一些配置的初始化），因为它能够保证其他对象读取到一致的信息。例如在某个服务器程序中，该服务器的配置信息可能存放在数据库或 文件中，这些配置数据由某个单例对象统一读取，服务进程中的其他对象如果要获取这些配置信息，只需访问该单例对象即可。这种方式极大地简化了在复杂环境 下，尤其是多线程环境下的配置管理，但是随着应用场景的不同，也可能带来一些同步问题。
1、饿汉式单例
public class Singleton {
private Singleton() {}
private static final Singleton single = new Singleton();
public static Singleton getInstance() {
　　上面例子中，在这个类被加载时，静态变量single会被初始化，此时类的私有构造子会被调用。这时单例类的唯一实例就被构造出来了。
　　饿汉式其实是一种比较形象的称谓。既然饿，那么在创建对象实例的时候就比较着急，饿了嘛，于是在装载类的时候就创建对象实例—&
private static final Singleton single = new Singleton();
　　饿汉式是典型的空间换时间，当类装载时就会创建类的实例，不管你用不用，先创建出来，然后每次调用的时候，就不需要再判断，节省了运行时间。
2、懒汉式单例
public class Singleton {
private Singleton() {}
private static Singleton single=null;
public static synchronized Singleton getInstance() {
if (single == null) {
single = new Singleton();
　　上面的懒汉式单例类实现里对静态工厂方法使用了同步化，以处理多线程环境。
　　懒汉式其实是一种比较形象的称谓。既然懒，那么在创建对象实例的时候就不着急。会一直等到马上要使用对象实例
的时候才会被创建，懒人嘛，总是推脱不开的时候才会真正执行工作，因此在装载对象的时候不创建对象实例。
private static Singleton single=null;
　　懒汉式是典型的时间换空间,就是每次获取实例都会进行判断，看是否需要创建实例，浪费判断的时间。当然，如果一直没有人使用的话，那就不会创建实例，则节约内存空间
　　由于懒汉式的实现是线程安全的，这样会降低整个访问的速度，而且每次都要判断。那么有没有更好的方式实现呢？
3、双重检查加锁
　　可以使用“双重检查加锁”的方式来实现，就可以达到实现线程安全，又能使性能不受很大影响。
　　双重检查加锁：并不是每次进入getInstance()都需要同步，而是先不同步，进入方法后，先检查单例对象是否存在，如果不存在才进行下面的同步块，这是第一重检查，进入同步块后，再次检查实例是否存在，如果不存在，就在同步的情况下创建一个实例（单例对象）,这是第二重检查。这样就只需要同步一次，从而减轻了多次在同步情况下进行判断所浪费的时间。
　　“双重检查加锁”机制的实现会使用关键字volatile，它的意思是：被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。不清楚volatile的看过来
代码实例：
public class Singleton {
private volatile static Singleton instance = null;
private Singleton(){}
public static Singleton getInstance(){
if(instance == null){
synchronized (Singleton.class) {
if(instance == null){
instance = new Singleton();
　　这种实现方式既可以实现线程安全地创建实例，而又不会对性能造成太大的影响。它只是第一次创建实例的时候同步，以后就不需要同步了，从而加快了运行速度。
　　提示：由于volatile关键字可能会屏蔽掉虚拟机中一些必要的代码优化，所以运行效率并不是很高。因此一般建议，没有特别的需要，不要使用。也就是说，虽然可以使用“双重检查加锁”机制来实现线程安全的单例，但并不建议大量采用，可以根据情况来选用。
　　根据上面的分析，常见的两种单例实现方式都存在小小的缺陷，那么有没有一种方案，既能实现延迟加载，又能实现线程安全呢？那就是下面一种方法，放大招了，接着呦。
4、静态内部类
public class Singleton {
private Singleton(){}
类级的内部类，也就是静态的成员式内部类，该内部类的实例与外部类的实例
没有绑定关系，而且只有被调用到时才会装载，从而实现了延迟加载。
private static class SingletonHolder{
* 静态初始化器，由JVM来保证线程安全
private static Singleton instance = new Singleton();
public static Singleton getInstance(){
return SingletonHolder.
当getInstance方法第一次被调用的时候，它第一次读取SingletonHolder.instance，导致SingletonHolder类得到初始化；而这个类在装载并被初始化的时候，会初始化它的静态域，从而创建Singleton的实例，由于是静态的域，因此只会在虚拟机装载类的时候初始化一次，并由虚拟机来保证它的线程安全性。
5、单例和枚举
public enum Singleton {
* 定义一个枚举的元素，它就代表了Singleton的一个实例。
* 单例可以有自己的操作
public void singletonOperation(){
按照《高效Java 第二版》中的说法：单元素的枚举类型已经成为实现Singleton的最佳方法。用枚举来实现单例非常简单，只需要编写一个包含单个元素的枚举类型即可。
　　对我来说，我比较喜欢第一种和第四种方式，简单易懂。而且在JVM层实现了线程安全（如果不是多个类加载器环境）。一般的情况下，我会使用第一种方式，只有在要明确实现lazy loading效果时才会使用第四种方式
五、Android中典型的单例模式Application类
1、Application是什么？
　　Application和Activity,Service一样,是android框架的一个系统组件，当android程序启动时系统会创建一个 application对象，用来存储系统的一些信息。通常我们是不需要指定一个Application的，这时系统会自动帮我们创建，如果需要创建自己 的Application，也很简单创建一个类继承 Application并在manifest的application标签中进行注册(只需要给Application标签增加个name属性把自己的 Application的名字定入即可)。
　　android系统会为每个程序运行时创建一个Application类的对象且仅创建一个，所以Application可以说是单例 (singleton)模式的一个类.且application对象的生命周期是整个程序中最长的，它的生命周期就等于这个程序的生命周期。因为它是全局 的单例的，所以在不同的Activity,Service中获得的对象都是同一个对象。所以通过Application来进行一些，数据传递，数据共享 等,数据缓存等操作。
2、巧妙运用单例模式特点，通过Application来传递数据
　　假如有一个Activity A, 跳转到 Activity B ,并需要推荐一些数据，通常的作法是Intent.putExtra() 让Intent携带，或者有一个Bundle把信息加入Bundle让Intent推荐Bundle对象，实现传递。但这样作有一个问题在 于，Intent和Bundle所能携带的数据类型都是一些基本的数据类型，如果想实现复杂的数据传递就比较麻烦了，通常需要实现 Serializable或者Parcellable接口。这其实是Android的一种IPC数据传递的方法。如果我们的两个Activity在同一个 进程当中为什么还要这么麻烦呢，只要把需要传递的对象的引用传递过去就可以了。
基本思路是这样的。在Application中创建一个HashMap ，以字符串为索引，Object为value这样我们的HashMap就可以存储任何类型的对象了。在Activity A中把需要传递的对象放入这个HashMap，然后通过Intent或者其它途经再把这索引的字符串传递给Activity B ,Activity B 就可以根据这个字符串在HashMap中取出这个对象了。只要再向下转个型 ，就实现了对象的传递。
经过网上的爬文终于了解了什么是单例模式，在这里感谢
没有更多推荐了，