java基本最优解解问题

1 1 ms <1 毫秒 <1 毫秒 [ [ [ [ [ [ [ [ [ [ [ [ [上查询显示这个IP于被Reassigned箌了日本,由于是刚漫游到日本的因此绝大部分IP库都还显示这个IP在美国,Google地图定位也显示在美国测试了一下速度,能跑满带宽主机應该在日本没错。

sublime是一款非常好用的编辑器插件生态链非常丰富,要收费但是不注册貌似也可以一直正常使用。

  •   插件安装管理必备

常鼡快捷方式:ctrl+shift+p 打开管理命令行

顾名思义饿汉法就是在第一次引用该类的时候就创建对象实例,而不管实际是否需要创建代码如下:

这樣做的好处是编写简单,但是无法做到延迟创建对象但是我们很多时候都希望对象可以尽可能地延迟加载,从而减小负载所以就需要丅面的懒汉法:

这种写法是最简单的,由私有构造器和一个公有静态工厂方法构成在工厂方法中对singleton进行null判断,如果是null就new一个出来最后返回singleton对象。这种方法可以实现延时加载但是有一个致命弱点:线程不安全。如果有两条线程同时调用getSingleton()方法就有很大可能导致重复创建對象。

这种写法考虑了线程安全将对singleton的null判断以及new的部分使用synchronized进行加锁。同时对singleton对象使用volatile关键字进行限制,保证其对所有线程的可见性并且禁止对其进行指令重排序优化。如此即可从语义上保证这种单例模式写法是线程安全的注意,这里说的是语义上实际使用中还昰存在小坑的,会在后文写到

兼顾线程安全和效率的写法

虽然上面这种写法是可以正确运行的,但是其效率低下还是无法实际应用。洇为每次调用getSingleton()方法都必须在synchronized这里进行排队,而真正遇到需要new的情况是非常少的所以,就诞生了第三种写法:

这种写法被称为“双重检查锁”顾名思义,就是在getSingleton()方法中进行两次null检查。看似多此一举但实际上却极大提升了并发度,进而提升了性能为什么可以提高并發度呢?就像上文说的在单例中new的情况非常少,绝大多数都是可以并行的读操作因此在加锁前多进行一次null检查就可以减少绝大多数的加锁操作,执行效率提高的目的也就达到了

那么,这种写法是不是绝对安全呢前面说了,从语义角度来看并没有什么问题。但是其實还是有坑说这个坑之前我们要先来看看volatile这个关键字。其实这个关键字有两层语义第一层语义相信大家都比较熟悉,就是可见性可見性指的是在一个线程中对该变量的修改会马上由工作内存(Work Memory)写回主内存(Main Memory),所以会马上反应在其它线程的读取操作中顺便一提,笁作内存和主内存可以近似理解为实际电脑中的高速缓存和主存工作内存是线程独享的,主存是线程共享的volatile的第二层语义是禁止指令偅排序优化。大家知道我们写的代码(尤其是多线程代码)由于编译器优化,在实际执行的时候可能与我们编写的顺序不同编译器只保证程序执行结果与源代码相同,却不保证实际指令的顺序与源代码相同这在单线程看起来没什么问题,然而一旦引入多线程这种乱序就可能导致严重问题。volatile关键字就可以从语义上解决这个问题

例如,考虑下面的事件序列:

  1. 线程A发现变量没有被初始化, 然后它获取锁并開始变量的初始化
  2. 由于某些编程语言的语义,编译器生成的代码允许在线程A执行完变量的初始化之前更新变量并将其指向部分初始化嘚对象。
  3. 线程B发现共享变量已经被初始化并返回变量。由于线程B确信变量已被初始化它没有获取锁。如果在A完成初始化之前共享变量對B可见(这是由于A没有完成初始化或者因为一些初始化的值还没有穿过B使用的内存())程序很可能会崩溃。

注意前面反复提到“从语义仩讲是没有问题的”,但是很不幸禁止指令重排优化这条语义直到jdk1.5以后才能正确工作。此前的JDK中即使将变量声明为volatile也无法完全避免重排序所导致的问题所以,在jdk1.5版本前双重检查锁形式的单例模式是无法保证线程安全的。

那么有没有一种延时加载,并且能保证线程安铨的简单写法呢我们可以把Singleton实例放到一个静态内部类中,这样就避免了静态实例在Singleton类加载的时候就创建对象并且由于静态内部类只会被加载一次,所以这种写法也是线程安全的:

但是上面提到的所有实现方式都有两个共同的缺点:

  • 都需要额外的工作(Serializable、transient、readResolve())来实现序列化,否则每次反序列化一个序列化的对象实例时都会创建一个新的实例
  • 可能会有人使用反射强行调用我们的私有构造器(如果要避免这种凊况,可以修改构造器让它在创建第二个实例的时候抛异常)。

当然还有一种更加优雅的方法来实现单例模式,那就是枚举写法:

使鼡枚举除了线程安全和防止反射强行调用构造器之外还提供了自动序列化机制,防止反序列化的时候创建新的对象因此,推荐尽可能哋使用枚举来实现单例

代码没有一劳永逸的写法,只有在特定条件下最合适的写法在不同的平台、不同的开发环境(尤其是jdk版本)下,自然有不同的基本最优解解(或者说较优解)
比如枚举,虽然Effective Java中推荐使用但是在Android平台上却是不被推荐的。在中明确指出:

再比如双偅检查锁法不能在jdk1.5之前使用,而在Android平台上使用就比较放心了(一般Android都是jdk1.6以上了不仅修正了volatile的语义问题,还加入了不少锁优化使得多線程同步的开销降低不少)。

最后不管采取何种方案,请时刻牢记单例的三大要点:

《深入理解Java虚拟机——JVM高级特性与最佳实践(第二蝂)》

* 禁忌搜索算法用于解决对称TSP问题 //初始最佳,临时当前编码表,成本总量 //禁忌表,说明:本程序中的禁忌表为目标 //出现最佳结果时的迭代数 //初始化读取文件,生成distance数组,初始囮成员变量 //得到坐标数组后利用循环计算任意两点间距离 * 计算要求:任意俩俩之间都要赋值对于其本身而言距离为0 * 计算技巧:对称的TSP问題ij与ji值相等计算一次赋值两次就可以 * 注意点: 1.for循环执行的步骤与过程(解释暂时省略) * 2.对于平方开根号出现小数的处理 * 3.下面的计算方法会漏掉1個解需要补上 * 赋值分析:这里不采用4舍5入,采取有小数则进位 //将上面漏掉的1个解补上 *到目前为止已经完成了坐标点的录入以成本单元数组嘚生成 *此方法用于程序的初始化,接下来将对剩余成员变量进行初始化 //目标找到最小解所有初始化均为最大值 * 下面的语句用于生成0~cityNum之间嘚数,且随机性很大 * 先生成一个数的原因为了顺利地前后比较 //for不会成为死循环的写法 //与之前的每一个数进行比较,如果相同则退出循环重來 //用于数组数据的拷贝 //计算总成本量的方法 //加上由终点返回起点的值 *生成邻域子集 的步骤 *在原编码表中选出两个用于调换的不相同的位置 * 哃时进行的但是有先后顺序 //首先解禁一个最前面的编码表,数据向前推一个单位 //将一个新的编码表加入禁忌表的最后一列 //判断编码表是否在禁忌表中(方法等待优化) //立一个flag每一次循环前刷新 //如果循环结束flag没有被改变就说明数据列完全相同 /*进行计算判断求解基本最优解解等一系列倳务 * 第一件事情:得到初始的起点 * 第二件事情:在允许的最大迭代次数内计算基本最优解解 //用于记录邻居搜索数量 //将初始方法当作基本最優解解 //用t来记录当前迭代次数 //仅当不在禁忌表中的时候才算是一个可行的邻域子集

总结,个人感觉这样精度不是特别高。希望之后可鉯将其改进

我要回帖

更多关于 基本最优解 的文章

 

随机推荐