线程安全

单例模式 单例模式就是一个类只允许有一个实例，并且向外界提供一个访问该实例的全局访问点。 单利模式的优点 由于单例模式只生成一个实例，减少了系统性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后永久驻留内存的方式来解决 – 单例模式可以在系统设置全局的访问点，优化环共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理 常见的五种单利模式的实现方式 主要： 饿汉式（线程安全，调用效率高。 但是，不能延时加载。） 懒汉式（线程安全，调用效率不高。 但是，可以延时加载。） 其他： 双重检测锁式（由于JVM底层内部模型原因，偶尔会出问题。不建议使用） 静态内部类式(线程安全，调用效率高。 但是，可以延时加载) 枚举单例(线程安全，调用效率高，不能延时加载) 来源： https://www.cnblogs.com/Scorpicat/p/12168488.html

Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized ”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。 锁提供了两种主要特性： 互斥（mutual exclusion） 和 可见性（visibility） 。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。 Volatile 变量 Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器

关于PHP的ts和nts 的简介： ts(Thread-Safety)即线程安全： 多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他 线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。php以ISAPI方式加载的时候选择这个版本. nts(None-Thread Safe)即非线程安全： 就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的是脏数据。php以fast cgi方式运行的时候选择这个版本，具有更好的性能； 主要是通过phpinfo();打印环境查看其中的 Thread Safety 项，这个项目就是查看是否是线程安全如果是：enabled，一般来说应该是ts版，否则是nts版。 来源： 51CTO 作者： gzxiaomei 链接： https://blog.51cto.com/13959155/2464914

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> http://blog.csdn.net/dqjyong/article/details/7668601(原博客) 以下是对原博客的整理 导航： 读写属性：（readwrite/readonly）以及（getter=name）、（setter=name） setter语意：（assign/retain/copy） 原子性： （non）atomic 从OC 2.0开始，我们能让系统自动生成设置变量值的方法或获取变量值的方法，即系统会自动为我们生成setter/getter方法。 @property（attribution）Vartype Varname； Setter and Getter 提醒一下，采用@property与自定义setter和getter方式其实是等价的，但是编译器会优先查找自动的setter/getter方法，如果找不到，就会使用@property对应的属性。 @propert（nonatomic ,copy）NSString *name; 这条语句等价于： 完成setter方法为： -(void)setName:(NSString*)newName{ if(newName!=name){ [name release]; name=[newName copy]; } } 完成getter方法为

记录Java容器中的常见概念和原理 参考： https://github.com/wangzhiwubigdata/God-Of-BigData#%E4%B8%89Java%E5%B9%B6%E5%8F%91%E5%AE%B9%E5%99%A8 https://blog.csdn.net/justloveyou_/article/details/78653929 基础容器 ArrayList(动态数组)、LinkedList(带头结点的双向链表) ArrayList public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, Cloneable, java.io.Serializable 默认初始容量为 10； 扩容机制：添加元素前，先检查是否需要扩容，一般扩为源数组的 1.5 倍 + 1； 边界检查（即检查 ArrayList 的 Size）：涉及到 index 的操作； 调整数组容量（减少容量）：将底层数组的容量调整为当前列表保存的实际元素的大小； 在查找给定元素索引值等的方法中，源码都将该元素的值分为null和不为null两种情况处理； LinkedList LinkedList 不但实现了List接口，还实现了Dequeue接口。因此

高并发下的数据安全 我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。 超发的原因 假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。） 优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false <?php //优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false include('./mysql.php'); $username =

原文地址：http://www.ibm.com/developerworks/cn/java/j-jtp06197.html Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized ”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。 锁提供了两种主要特性： 互斥（mutual exclusion） 和 可见性（visibility） 。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。 Volatile 变量 Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例

简介： Java™ 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量。这两种机制的提出都是为了实现代码线程的安全性。其中 Volatile 变量的同步性较差（但有时它更简单并且开销更低），而且其使用也更容易出错。在这期的 Java 理论与实践 中，Brian Goetz 将介绍几种正确使用 volatile 变量的模式，并针对其适用性限制提出一些建议。 Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized ”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。 锁提供了两种主要特性： 互斥（mutual exclusion） 和 可见性（visibility） 。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值

本文转自：http://www.ibm.com/developerworks/cn/java/j-jtp06197.html 由Java并发大师Brian Goetz所撰写的。 Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized ”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。 锁提供了两种主要特性： 互斥（mutual exclusion） 和 可见性（visibility） 。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些， 它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。 Volatile 变量 Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性 。这就是说线程能够自动发现 volatile 变量的最新值。Volatile

Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized ”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。 锁提供了两种主要特性： 互斥（mutual exclusion） 和 可见性（visibility） 。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。 Volatile 变量 Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器