Java开发中的23种设计模式详解

tuonioooo 2015-10-10 10:31:36
加精
在GoF的23种设计模式中,单例模式是比较简单的一种。然而,有时候越是简单的东西越容易出现问题。下面就单例设计模式详细的探讨一下。

所谓单例模式,简单来说,就是在整个应用中保证只有一个类的实例存在。就像是Java Web中的application,也就是提供了一个全局变量,用处相当广泛,比如保存全局数据,实现全局性的操作等。

1. 最简单的实现

首先,能够想到的最简单的实现是,把类的构造函数写成private的,从而保证别的类不能实例化此类,然后在类中提供一个静态的实例并能够返回给使用者。这样,使用者就可以通过这个引用使用到这个类的实例了。

public class SingletonClass {

private static final SingletonClass instance = new SingletonClass();

public static SingletonClass getInstance() {
return instance;
}

private SingletonClass() {

}

}

如上例,外部使用者如果需要使用SingletonClass的实例,只能通过getInstance()方法,并且它的构造方法是private的,这样就保证了只能有一个对象存在。

2. 性能优化——lazy loaded

上面的代码虽然简单,但是有一个问题——无论这个类是否被使用,都会创建一个instance对象。如果这个创建过程很耗时,比如需要连接10000次数据库(夸张了…:-)),并且这个类还并不一定会被使用,那么这个创建过程就是无用的。怎么办呢?

为了解决这个问题,我们想到了新的解决方案:

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}

private SingletonClass() {

}

}

代码的变化有两处——首先,把instance初始化为null,直到第一次使用的时候通过判断是否为null来创建对象。因为创建过程不在声明处,所以那个final的修饰必须去掉。

我们来想象一下这个过程。要使用SingletonClass,调用getInstance()方法。第一次的时候发现instance是null,然后就新建一个对象,返回出去;第二次再使用的时候,因为这个instance是static的,所以已经不是null了,因此不会再创建对象,直接将其返回。

这个过程就成为lazy loaded,也就是迟加载——直到使用的时候才进行加载。

3. 同步

上面的代码很清楚,也很简单。然而就像那句名言:“80%的错误都是由20%代码优化引起的”。单线程下,这段代码没有什么问题,可是如果是多线程,麻烦就来了。我们来分析一下:

线程A希望使用SingletonClass,调用getInstance()方法。因为是第一次调用,A就发现instance是null的,于是它开始创建实例,就在这个时候,CPU发生时间片切换,线程B开始执行,它要使用SingletonClass,调用getInstance()方法,同样检测到instance是null——注意,这是在A检测完之后切换的,也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后,切换到A继续执行,因为它已经检测完了,所以A不会再检测一遍,它会直接创建对象。这样,线程A和B各自拥有一个SingletonClass的对象——单例失败!

解决的方法也很简单,那就是加锁:

public class SingletonClass {

private static SingletonClass instance = null;

public synchronized static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}

private SingletonClass() {

}

}

是要getInstance()加上同步锁,一个线程必须等待另外一个线程创建完成后才能使用这个方法,这就保证了单例的唯一性。

4. 又是性能

上面的代码又是很清楚很简单的,然而,简单的东西往往不够理想。这段代码毫无疑问存在性能的问题——synchronized修饰的同步块可是要比一般的代码段慢上几倍的!如果存在很多次getInstance()的调用,那性能问题就不得不考虑了!

让我们来分析一下,究竟是整个方法都必须加锁,还是仅仅其中某一句加锁就足够了?我们为什么要加锁呢?分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行,那么单例就已经保证了。于是,我们开始修改代码:

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
return instance;
}

private SingletonClass() {

}

}

首先去掉getInstance()的同步操作,然后把同步锁加载if语句上。但是这样的修改起不到任何作用:因为每次调用getInstance()的时候必然要同步,性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢?

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
if (instance == null) {
synchronized (SingletonClass.class) {
if (instance == null) {
instance = new SingletonClass();
}
}
}
return instance;
}

private SingletonClass() {

}

}

还有问题吗?首先判断instance是不是为null,如果为null,加锁初始化;如果不为null,直接返回instance。

这就是double-checked locking设计实现单例模式。到此为止,一切都很完美。我们用一种很聪明的方式实现了单例模式。

5. 从源头检查

下面我们开始说编译原理。所谓编译,就是把源代码“翻译”成目标代码——大多数是指机器代码——的过程。针对Java,它的目标代码不是本地机器代码,而是虚拟机代码。编译原理里面有一个很重要的内容是编译器优化。所谓编译器优化是指,在不改变原来语义的情况下,通过调整语句顺序,来让程序运行的更快。这个过程成为reorder。

要知道,JVM只是一个标准,并不是实现。JVM中并没有规定有关编译器优化的内容,也就是说,JVM实现可以自由的进行编译器优化。

下面来想一下,创建一个变量需要哪些步骤呢?一个是申请一块内存,调用构造方法进行初始化操作,另一个是分配一个指针指向这块内存。这两个操作谁在前谁在后呢?JVM规范并没有规定。那么就存在这么一种情况,JVM是先开辟出一块内存,然后把指针指向这块内存,最后调用构造方法进行初始化。

下面我们来考虑这么一种情况:线程A开始创建SingletonClass的实例,此时线程B调用了getInstance()方法,首先判断instance是否为null。按照我们上面所说的内存模型,A已经把instance指向了那块内存,只是还没有调用构造方法,因此B检测到instance不为null,于是直接把instance返回了——问题出现了,尽管instance不为null,但它并没有构造完成,就像一套房子已经给了你钥匙,但你并不能住进去,因为里面还没有收拾。此时,如果B在A将instance构造完成之前就是用了这个实例,程序就会出现错误了!

于是,我们想到了下面的代码:

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
if (instance == null) {
SingletonClass sc;
synchronized (SingletonClass.class) {
sc = instance;
if (sc == null) {
synchronized (SingletonClass.class) {
if(sc == null) {
sc = new SingletonClass();
}
}
instance = sc;
}
}
}
return instance;
}

private SingletonClass() {

}

}

我们在第一个同步块里面创建一个临时变量,然后使用这个临时变量进行对象的创建,并且在最后把instance指针临时变量的内存空间。写出这种代码基于以下思想,即synchronized会起到一个代码屏蔽的作用,同步块里面的代码和外部的代码没有联系。因此,在外部的同步块里面对临时变量sc进行操作并不影响instance,所以外部类在instance=sc;之前检测instance的时候,结果instance依然是null。

不过,这种想法完全是错误的!同步块的释放保证在此之前——也就是同步块里面——的操作必须完成,但是并不保证同步块之后的操作不能因编译器优化而调换到同步块结束之前进行。因此,编译器完全可以把instance=sc;这句移到内部同步块里面执行。这样,程序又是错误的了!

6. 解决方案

说了这么多,难道单例没有办法在Java中实现吗?其实不然!

在JDK 5之后,Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前,volatile是个关键字,但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整,读变量不能和之后的读写代码调整!因此,只要我们简单的把instance加上volatile关键字就可以了。

public class SingletonClass {

private volatile static SingletonClass instance = null;

public static SingletonClass getInstance() {
if (instance == null) {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
}
return instance;
}

private SingletonClass() {

}

}

然而,这只是JDK1.5之后的Java的解决方案,那之前版本呢?其实,还有另外的一种解决方案,并不会受到Java版本的影响:

public class SingletonClass {

private static class SingletonClassInstance {
private static final SingletonClass instance = new SingletonClass();
}

public static SingletonClass getInstance() {
return SingletonClassInstance.instance;
}

private SingletonClass() {

}

}

在这一版本的单例模式实现代码中,我们使用了Java的静态内部类。这一技术是被JVM明确说明了的,因此不存在任何二义性。在这段代码中,因为SingletonClass没有static的属性,因此并不会被初始化。直到调用getInstance()的时候,会首先加载SingletonClassInstance类,这个类有一个static的SingletonClass实例,因此需要调用SingletonClass的构造方法,然后getInstance()将把这个内部类的instance返回给使用者。由于这个instance是static的,因此并不会构造多次。

由于SingletonClassInstance是私有静态内部类,所以不会被其他类知道,同样,static语义也要求不会有多个实例存在。并且,JSL规范定义,类的构造必须是原子性的,非并发的,因此不需要加同步块。同样,由于这个构造是并发的,所以getInstance()也并不需要加同步。

至此,我们完整的了解了单例模式在Java语言中的时候,提出了两种解决方案。个人偏向于第二种,并且Effiective Java也推荐的这种方式。
...全文
52513 212 打赏 收藏 转发到动态 举报
写回复
用AI写文章
212 条回复
切换为时间正序
请发表友善的回复…
发表回复
weixin_43230320 2018-09-18
  • 打赏
  • 举报
回复
好 ,,,,,
qq_38466233 2018-09-14
  • 打赏
  • 举报
回复
疯狂打call 期待后续部分
qiaojieer520 2018-09-11
  • 打赏
  • 举报
回复
由浅到深,依次剖析,很受用
哈蒙 2018-09-05
  • 打赏
  • 举报
回复
不错,归纳的挺好的
倪古拉斯 2018-08-24
  • 打赏
  • 举报
回复
学习了!!!!!!!!1
  • 打赏
  • 举报
回复
https://www.guangboyuan.cn/ 这个网站有很多不错的学习视频,和大家分享下
weixin_37943875 2018-08-12
  • 打赏
  • 举报
回复
受教了啊!非常不错
都先生 2018-08-09
  • 打赏
  • 举报
回复
  • 打赏
  • 举报
回复
  • 打赏
  • 举报
回复
《软件设计模式》好书介绍 https://blog.csdn.net/weixin_42531524/article/details/81112585
  • 打赏
  • 举报
回复
引用 楼主 tuoni123 的回复:
在GoF的23种设计模式中,单例模式是比较简单的一种。然而,有时候越是简单的东西越容易出现问题。下面就单例设计模式详细的探讨一下。

所谓单例模式,简单来说,就是在整个应用中保证只有一个类的实例存在。就像是Java Web中的application,也就是提供了一个全局变量,用处相当广泛,比如保存全局数据,实现全局性的操作等。

1. 最简单的实现

首先,能够想到的最简单的实现是,把类的构造函数写成private的,从而保证别的类不能实例化此类,然后在类中提供一个静态的实例并能够返回给使用者。这样,使用者就可以通过这个引用使用到这个类的实例了。

public class SingletonClass {

private static final SingletonClass instance = new SingletonClass();

public static SingletonClass getInstance() {
return instance;
}

private SingletonClass() {

}

}

如上例,外部使用者如果需要使用SingletonClass的实例,只能通过getInstance()方法,并且它的构造方法是private的,这样就保证了只能有一个对象存在。

2. 性能优化——lazy loaded

上面的代码虽然简单,但是有一个问题——无论这个类是否被使用,都会创建一个instance对象。如果这个创建过程很耗时,比如需要连接10000次数据库(夸张了…:-)),并且这个类还并不一定会被使用,那么这个创建过程就是无用的。怎么办呢?

为了解决这个问题,我们想到了新的解决方案:

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}

private SingletonClass() {

}

}

代码的变化有两处——首先,把instance初始化为null,直到第一次使用的时候通过判断是否为null来创建对象。因为创建过程不在声明处,所以那个final的修饰必须去掉。

我们来想象一下这个过程。要使用SingletonClass,调用getInstance()方法。第一次的时候发现instance是null,然后就新建一个对象,返回出去;第二次再使用的时候,因为这个instance是static的,所以已经不是null了,因此不会再创建对象,直接将其返回。

这个过程就成为lazy loaded,也就是迟加载——直到使用的时候才进行加载。

3. 同步

上面的代码很清楚,也很简单。然而就像那句名言:“80%的错误都是由20%代码优化引起的”。单线程下,这段代码没有什么问题,可是如果是多线程,麻烦就来了。我们来分析一下:

线程A希望使用SingletonClass,调用getInstance()方法。因为是第一次调用,A就发现instance是null的,于是它开始创建实例,就在这个时候,CPU发生时间片切换,线程B开始执行,它要使用SingletonClass,调用getInstance()方法,同样检测到instance是null——注意,这是在A检测完之后切换的,也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后,切换到A继续执行,因为它已经检测完了,所以A不会再检测一遍,它会直接创建对象。这样,线程A和B各自拥有一个SingletonClass的对象——单例失败!

解决的方法也很简单,那就是加锁:

public class SingletonClass {

private static SingletonClass instance = null;

public synchronized static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}

private SingletonClass() {

}

}

是要getInstance()加上同步锁,一个线程必须等待另外一个线程创建完成后才能使用这个方法,这就保证了单例的唯一性。

4. 又是性能

上面的代码又是很清楚很简单的,然而,简单的东西往往不够理想。这段代码毫无疑问存在性能的问题——synchronized修饰的同步块可是要比一般的代码段慢上几倍的!如果存在很多次getInstance()的调用,那性能问题就不得不考虑了!

让我们来分析一下,究竟是整个方法都必须加锁,还是仅仅其中某一句加锁就足够了?我们为什么要加锁呢?分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行,那么单例就已经保证了。于是,我们开始修改代码:

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
return instance;
}

private SingletonClass() {

}

}

首先去掉getInstance()的同步操作,然后把同步锁加载if语句上。但是这样的修改起不到任何作用:因为每次调用getInstance()的时候必然要同步,性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢?

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
if (instance == null) {
synchronized (SingletonClass.class) {
if (instance == null) {
instance = new SingletonClass();
}
}
}
return instance;
}

private SingletonClass() {

}

}

还有问题吗?首先判断instance是不是为null,如果为null,加锁初始化;如果不为null,直接返回instance。

这就是double-checked locking设计实现单例模式。到此为止,一切都很完美。我们用一种很聪明的方式实现了单例模式。

5. 从源头检查

下面我们开始说编译原理。所谓编译,就是把源代码“翻译”成目标代码——大多数是指机器代码——的过程。针对Java,它的目标代码不是本地机器代码,而是虚拟机代码。编译原理里面有一个很重要的内容是编译器优化。所谓编译器优化是指,在不改变原来语义的情况下,通过调整语句顺序,来让程序运行的更快。这个过程成为reorder。

要知道,JVM只是一个标准,并不是实现。JVM中并没有规定有关编译器优化的内容,也就是说,JVM实现可以自由的进行编译器优化。

下面来想一下,创建一个变量需要哪些步骤呢?一个是申请一块内存,调用构造方法进行初始化操作,另一个是分配一个指针指向这块内存。这两个操作谁在前谁在后呢?JVM规范并没有规定。那么就存在这么一种情况,JVM是先开辟出一块内存,然后把指针指向这块内存,最后调用构造方法进行初始化。

下面我们来考虑这么一种情况:线程A开始创建SingletonClass的实例,此时线程B调用了getInstance()方法,首先判断instance是否为null。按照我们上面所说的内存模型,A已经把instance指向了那块内存,只是还没有调用构造方法,因此B检测到instance不为null,于是直接把instance返回了——问题出现了,尽管instance不为null,但它并没有构造完成,就像一套房子已经给了你钥匙,但你并不能住进去,因为里面还没有收拾。此时,如果B在A将instance构造完成之前就是用了这个实例,程序就会出现错误了!

于是,我们想到了下面的代码:

public class SingletonClass {

private static SingletonClass instance = null;

public static SingletonClass getInstance() {
if (instance == null) {
SingletonClass sc;
synchronized (SingletonClass.class) {
sc = instance;
if (sc == null) {
synchronized (SingletonClass.class) {
if(sc == null) {
sc = new SingletonClass();
}
}
instance = sc;
}
}
}
return instance;
}

private SingletonClass() {

}

}

我们在第一个同步块里面创建一个临时变量,然后使用这个临时变量进行对象的创建,并且在最后把instance指针临时变量的内存空间。写出这种代码基于以下思想,即synchronized会起到一个代码屏蔽的作用,同步块里面的代码和外部的代码没有联系。因此,在外部的同步块里面对临时变量sc进行操作并不影响instance,所以外部类在instance=sc;之前检测instance的时候,结果instance依然是null。

不过,这种想法完全是错误的!同步块的释放保证在此之前——也就是同步块里面——的操作必须完成,但是并不保证同步块之后的操作不能因编译器优化而调换到同步块结束之前进行。因此,编译器完全可以把instance=sc;这句移到内部同步块里面执行。这样,程序又是错误的了!

6. 解决方案

说了这么多,难道单例没有办法在Java中实现吗?其实不然!

在JDK 5之后,Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前,volatile是个关键字,但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整,读变量不能和之后的读写代码调整!因此,只要我们简单的把instance加上volatile关键字就可以了。

public class SingletonClass {

private volatile static SingletonClass instance = null;

public static SingletonClass getInstance() {
if (instance == null) {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
}
return instance;
}

private SingletonClass() {

}

}

然而,这只是JDK1.5之后的Java的解决方案,那之前版本呢?其实,还有另外的一种解决方案,并不会受到Java版本的影响:

public class SingletonClass {

private static class SingletonClassInstance {
private static final SingletonClass instance = new SingletonClass();
}

public static SingletonClass getInstance() {
return SingletonClassInstance.instance;
}

private SingletonClass() {

}

}

在这一版本的单例模式实现代码中,我们使用了Java的静态内部类。这一技术是被JVM明确说明了的,因此不存在任何二义性。在这段代码中,因为SingletonClass没有static的属性,因此并不会被初始化。直到调用getInstance()的时候,会首先加载SingletonClassInstance类,这个类有一个static的SingletonClass实例,因此需要调用SingletonClass的构造方法,然后getInstance()将把这个内部类的instance返回给使用者。由于这个instance是static的,因此并不会构造多次。

由于SingletonClassInstance是私有静态内部类,所以不会被其他类知道,同样,static语义也要求不会有多个实例存在。并且,JSL规范定义,类的构造必须是原子性的,非并发的,因此不需要加同步块。同样,由于这个构造是并发的,所以getInstance()也并不需要加同步。

至此,我们完整的了解了单例模式在Java语言中的时候,提出了两种解决方案。个人偏向于第二种,并且Effiective Java也推荐的这种方式。


软件设计类好书介绍 https://blog.csdn.net/weixin_42531524/article/details/81112585
I am leeb 2018-07-27
  • 打赏
  • 举报
回复
赶紧来学习一下!!
Defonds 2018-07-11
  • 打赏
  • 举报
回复
verejava 2018-07-07
  • 打赏
  • 举报
回复
study_wx 2018-07-06
  • 打赏
  • 举报
回复
感谢分享,论坛有你更精彩
Defonds 2018-07-03
  • 打赏
  • 举报
回复
weixin_39974334 2018-06-28
  • 打赏
  • 举报
回复
好好学习中,初学者,请大家多多关照
  • 打赏
  • 举报
回复
单例模式讲的真好,定一个
  • 打赏
  • 举报
回复
666666666666
weixin_42409423 2018-06-20
  • 打赏
  • 举报
回复
很好123123123
加载更多回复(191)
[14本经典Android开发教程] 8 Linux内核阅读心得体会 读核感悟 2 读核感悟 Linux内核启动 内核的生成 2 读核感悟 Linux内核启动 从hello world说起 3 读核感悟 Linux内核启动 BIOS 5 读核感悟 Linux内核启动 setup辅助程序 6 读核感悟 Linux内核启动 内核解压缩 8 读核感悟 Linux内核启动 开启页面映射 9 读核感悟 Linux内核启动 链接脚本 11 读核感悟 伪装现场 系统调用参数 13 读核感悟 伪装现场 fork 系统调用 15 读核感悟 伪装现场 内核线程: 17 读核感悟 伪装现场 信号通信 19 读核感悟 kbuild系统 内核模块的编译 22 读核感悟 kbuild系统 编译到内核和编译成模块的区别 24 读核感悟 kbuild系统 make bzImage的过程 26 读核感悟 kbuild系统 make menuconfig 31 读核感悟 文件系统 用C来实现面向对象 32 读核感悟 设计模式 用C来实现虚函数表和多态 32 读核感悟 设计模式 用C来实现继承和模板 33 读核感悟 设计模式 文件系统和设备的继承和接口 34 读核感悟 设计模式 文件系统与抽象工厂 36 读核感悟 阅读源代码技巧 查找定义 37 读核感悟 阅读源代码技巧 变量命名规则 42 读核感悟 内存管理 内核的页表映射总结 43 读核感悟 健壮的代码 exception table 内核的刑事档案 44 读核感悟 定时器 巧妙的定时器算法 45 读核感悟 内存管理 page fault处理流程 45 读核感悟 文件读写 select实现原理 47 读核感悟 文件读写 poll的实现原理 49 1 功能介绍: 49 2 关键的结构体: 49 3 poll的实现 49 4 性能分析: 50 读核感悟 文件读写 epoll的实现原理 50 1 功能介绍 50 2 关键结构体: 51 3 epoll create的实现 53 4 epoll ctl的实现 53 5 epoll wait的实现 54 6 性能分析 54 读核感悟 同步问题 同步问题概述 55 1 同步问题的产生背景 55 2 内核态与用户态的区别 55 读核感悟 同步问题 内核态自旋锁的实现 56 1自旋锁的总述 56 2非抢占式的自旋锁 56 3 锁的释放 57 4 与用户态的自旋锁的比较 57 5 总结 58 读核感悟 内存管理 free命令详解 58 读核感悟 文件读写 2 6 9内核的AIO 59 1 AIO概述 59 2 内核态AIO的使用 61 读核感悟 文件读写 内核态AIO相关结构体 61 1 内核态AIO操作相关信息 61 2 AIO上下文: 63 3 AIO ring 63 4 异步I O事件的返回信息 64 读核感悟 文件读写 内核态AIO创建和提交操作 65 1 AIO上下文的创建 io setup 65 2 AIO请求的提交:io submit实现机制 66 读核感悟 文件操作 AIO操作的执行 66 1 在提交时执行AIO 66 2 在工作队列执行AIO 66 3 负责AIO执行的核心函数aio run iocb 67 4 AIO操作的完成 67 读核感悟 文件读写 内核态是否支持非direct I O方式的AIO 67 已上传7本: [14本经典Android开发教程] 1 Android开发从入门到精通 http: download csdn net detail cleopard 8355245 [14本经典Android开发教程] 2 Android开发手册 API函数详解 http: download csdn net detail cleopard 8374487 [14本经典Android开发教程] 3 Android SDK 开发文档 http: download csdn net detail cleopard 8380429 [14本经典Android开发教程] 4 Android应用程序开发36技 http: download csdn net detail cleopard 8380495 [14本经典Android开发教程] 5 linux Android基础知识总结 http: download csdn net detail cleopard 8380529 [14本经典Android开发教程] 6 Android驱动开发入门及手机案例开发分析教程 http: download csdn net detail cleopard 8388019 [14本经典Android开发教程] 7 Android编程入门教程 http: download csdn net detail cleopard 8388043 剩余8本稍后上传 @或直接从这里寻找@ http: download csdn net user cleopard album @更多@ http: cleopard download csdn net 福利 http: xuemeilaile com 17份软件测试文档 http: download csdn net album detail 1425 13份WPF经典开发教程 http: download csdn net album detail 1115 C#资料合辑二[C#桌面编程入门篇] http: download csdn net album detail 957 C#资料合辑一[C#入门篇] http: download csdn net album detail 669 [Csharp高级编程 第6版 ] 共8压缩卷 http: download csdn net album detail 667 10个[精品资源]Java学习资料合辑[一] http: download csdn net album detail 663 10个C#Socket编程代码示例 http: download csdn net album detail 631 6份GDI+程序设计资源整合[全零分] http: download csdn net album detail 625 2014年移动游戏行业数据分析 http: download csdn net detail cleopard 8340331 一文读懂2014年全球互联网广告新生态 http: download csdn net detail cleopard 8340303">[14本经典Android开发教程] 8 Linux内核阅读心得体会 读核感悟 2 读核感悟 Linux内核启动 内核的生成 2 读核 [更多]

81,090

社区成员

发帖
与我相关
我的任务
社区描述
Java Web 开发
社区管理员
  • Web 开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧