js常用设计模式实现一单例模式

什么是设计模式设计模式是一种能够被反复使用,符合面向对象特性的代码设计经验的总结,合理的使用设计模式能够让你得代码更容易维护和可靠设计模式的类型共分为创建型模式,结构型模式,行为型模式三种 创建型模式创建型模式是对一个类的实例化过程进行了抽象,把对象的创建和对象的使用进行了分离,创建模式有 单例模式抽象工厂模式建造者模式工厂模式原型模式单例模式单例模式的定义是保证一个类仅有一个实例,单例模式它必须自行创建这个实例,并提供一个访问他的全局的访问点es5的实现var only = function(data) { this.data = data; this.Instance = null;}only.go = function(data) { if(!this.Instance) { this.Instance = new only(data); } return this.Instance;}let obj1 = only.go('1')let obj2 = only.go('2')console.log(obj1 === obj2);console.log(obj1);console.log(obj2);es6class only { constructor(data) { if (only.prototype.Instance === undefined) { this.data = data; only.prototype.Instance = this; } return only.prototype.Instance; }}let ob1 = new only("a");let ob2 = new only("b");ob2.init = 'init';console.log(ob1 === ob2);console.log(ob1);console.log(ob2);上边的代码中,无论怎么new,其结果都是唯一的那个实例 单例模式的优缺点单例模式,因为他的实例是唯一的,所以完全可以通过创建的时候,严格的去控制怎么去创建和访问或者说抛出错误,如果存在频繁的创建和销毁的操作的时候,单例模式事可以提高性能的 但是同样的,单纯的单例模式中是没有抽象操作的,所以说单例模式是一个不便于扩展的模式 ...

July 11, 2019 · 1 min · jiezi

OC基础-单例的实现 & 提醒自己注意多线程问题

做客户端开发应当时刻考虑多线程问题。我最初是做前端开发的,在这方面考虑得往往不够。谨记。单例的常见写法单例的常见写法其实就两种1. 依赖锁+ (id)sharedInstance { static testClass *sharedInstance = nil; @synchronized(self) { if (!sharedInstance) { sharedInstance = [[self alloc] init]; } } return sharedInstance; }2. 依赖dispatch_once+ (id)sharedInstance { static testClass *sharedInstance = nil; static dispatch_once_t once; dispatch_once(&once, ^{ sharedInstance = [[self alloc] init]; }); return sharedInstance; }dispatch_once的写法更推荐一些。一方面是性能上好一点,另一方面是语义上更直观。once,执行一次嘛。不管是用锁还是dispatch_once,本质上都是为了避免单例创建过程出现线程安全问题。更进一步,我们经常会有懒加载某些属性的写法:- (id<InterfaceEngineA>)engineA{ if (_engineA == nil) { _engineA = [EngineA new]; } return _engineA;}其实跟单例的实现是类似的,这种时候要格外注意线程安全问题。如果存在多线程场景,一定要做好保护- (id<InterfaceEngineA>)engineA{ @synchronized(self) { if (_engineA == nil) { _engineA = [EngineA new]; } } return _engineA;}一些废话多线程问题的表现可能是各种各样难以预料的。这里我遇到的是,_engineA在多线程场景下小概率被重复创建,其实例1在init时注册了网络层命令字cmd1的回包,而这个网络层框架的实现是,只接受第一个注册这一命令字的对象。导致实例2注册失败。后面调用实例2发送请求,回包都被实例1接收了。从日志上看,一切都挺正常的。但是下次取数据就是取不到。这个bug第一次提过来的时候,没分析出根本原因,只在表面上做了保护。结果第二次提过来才真正改掉。丢人呐。还是要好好学习才是。 ...

January 24, 2019 · 1 min · jiezi

Faiss优化:针对OMP_NUM_THREADS环境变量设置的测试验证

前言记录一下Faiss在项目使用中的一些优化,对OMP_NUM_THREADS 环境变量参数的测试验证~ OMP_NUM_THREADS 用于控制线程并发数. 测试条件:单个循环请求,持续时间大于15m; 基础数据:200w 软件环境:docker; ubuntu 16.04 ;python2.7; faiss:1.4.0-cpu 检索服务功能: (汉明距离计算 + 欧式距离计算 )结论: 测试总结如下: * CPU=1 & OMP_NUM_THREADS=1时, - 1m,5m,15m load average 分布为 31.54,41.16,43.43; - CPUs(%) 用户空间占比:32.1;内核空间占比:2.4;空闲占比:65.2; - faiss 检索耗时大约在5-6ms左右; - 检索服务整体响应时间较平稳,大部分在12ms左右; * CPU=3 & OMP_NUM_THREADS=1时, - 1m,5m,15m load average 分布为 49.17,48.70,50.54; - CPUs(%) 用户空间占比:39.5;内核空间占比:4.2;空闲占比:30.3; - faiss 检索耗时大约在5-7ms左右; - 检索服务整体响应时间较平稳,大部分耗时在12ms左右; * CPU=3 & OMP_NUM_THREADS=10时, - 1m,5m,15m load average 分布为 41.33,43.90,55.87; - CPUs(%) 用户空间占比:20.7;内核空间占比:2.3;空闲占比:58.0; - faiss 检索耗时不稳定,抖动较大, 大约在10-90ms左右; - 检索服务整体响应时间存在抖动,大约在14-92ms左右; * CPU=1 & OMP_NUM_THREADS=10时, - 1m,5m,15m load average 分布为 67.77,61.89,61.07; - CPUs(%) 用户空间占比:20.6;内核空间占比:2.9;空闲占比:18.2; - faiss 检索耗时不稳定,抖动较大, 大约在5-80ms左右; - 检索服务整体响应时间存在抖动,大约在13-99ms左右; 最终结论: a: OMP_NUM_THREADS=1时,faiss检索耗时较稳定; b: OMP_NUM_THREADS=10时,faiss检索耗时不稳定,抖动较大; b: OMP_NUM_THREADS=1时, 多核CPU相较于单核CPU,负载略高,利用率略高,空闲占比较低; c: OMP_NUM_THREADS=10时, 多核CPU相较于单核CPU,负载较低,利用率较低,空闲占比较高; d: 优化方向:OMP_NUM_THREADS=1 + 多进程测试结果统计:* CPU=1 & OMP_NUM_THREADS=1* CPU=3 & OMP_NUM_THREADS=1* CPU=3 & OMP_NUM_THREADS=10* CPU=1 & OMP_NUM_THREADS=10 ...

December 21, 2018 · 1 min · jiezi