悲观锁与乐观锁

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

转自:http://blog.csdn.net/hongchangfirst/article/details/26004335

看了很多,发现这个总结,太贴切。不知道怎么加自己观点了,只能实际运用加观点了。这里直接转载~

服务器tomcat自动停止问题

Linux下面有个机制叫OOM killer(Out Of Memory killer,这个东西会在系统内存耗尽或者即将耗尽的情况下跳出来执行,选择性的干掉一些进程以求释放一些内存。

可能会出现的问题就是,某天tomcat无缘无故停掉了,或者是 某天机器突然登不上了,能ping通,但是ssh死活连不了。原因是tomcat/sshd进程被OOM killer干掉了。在系统的日志中通常会有下面的打印日志:Out of memory: kill process 959 (sshd) score 55 or a child。 

1.       OOM什么时候出现?

我们在用户空间申请内存时,一般使用的是malloc,是不是当malloc返回为空时,没有可以申请的内存空间了就会返回呢?答案是否定的。在关于malloc的申请内存的机制中有下面的一段描述:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer. In case Linux is employed under circumstances where it would be less desirable to suddenly lose some randomly picked processes, and moreover the kernel version is sufficiently recent, one can switch off this overcommitting behavior using a command like:

上面的描述中说明了在Linux中当malloc返回的是非空时,并不代表有可以使用的内存空间。Linux系统允许程序申请比系统可用内存更多的内存空间,这个特性叫做overcommit特性,这样做可能是为了系统的优化,因为不是所有的程序申请了内存就会立刻使用,当真正的使用时,系统可能已经回收了一下内存。但是,当你使用时Linux系统没有内存可以使用时,OOM Killer就会出来让一些进程退出。

Linux下有3种Overcommit的策略(参考内核文档:vm/overcommit-accounting),可以在/proc/sys/vm/overcommit_memory配置(取0,1和2三个值,默认是0)。

(1)0:启发式策略,比较严重的Overcommit将不能得逞,比如你突然申请了128TB的内存。而轻微的overcommit将被允许。另外,root能Overcommit的值比普通用户要稍微多

(2)永远允许overcommit,这种策略适合那些不能承受内存分配失败的应用,比如某些科学计算应用。

(3)永远禁止overcommit,在这个情况下,系统所能分配的内存不会超过swap+RAM*系数(/proc/sys/vm/overcmmit_ratio,默认50%,你可以调整),如果这么多资源已经用光,那么后面任何尝试申请内存的行为都会返回错误,这通常意味着此时没法运行任何新程序。

/proc/sys/vm # cat overcommit_ratio

50

当然我可以修改proc//oom_adj的值,这里的默认值为0,当我们设置为-17时,对于该进程来说,就不会触发OOM机制,被杀掉。

echo -17 > /proc/$(pidof sshd)/oom_adj

这里为什么是-17呢?这和Linux的实现有关系。在Linux内核中的oom.h文件中,可以看到下面的定义:

/* /proc//oom_adj set to -17 protects from the oom-killer */

#define OOM_DISABLE (-17)

/* inclusive */

#define OOM_ADJUST_MIN (-16)

#define OOM_ADJUST_MAX 15

这个oom_adj中的变量的范围为15到-16之间。越大越容易被kill。oom_score就是它计算出来的一个值,就是根据这个值来选择哪些进程被kill掉的。

总之,通过上面的分析可知,满足下面的条件后,就是启动OOM机制。

1) VM里面分配不出更多的page(注意linux kernel是延迟分配page策略,及用到的时候才alloc;所以malloc + memset才有效)。

2) 用户地址空间不足,这种情况在32bit机器上及user space超过了3GB,在64bit机器上不太可能发生。

2     当该机制被触发后,会让什么样的进程退出?

只要存在overcommit,就可能会有OOM killer。 Linux系统的选择策略也一直在不断的演化。我们可以通过设置一些值来影响OOM killer做出决策。Linux下每个进程都有个OOM权重,在/proc//oom_adj里面,取值是-17到+15,取值越高,越容易被干掉。  最终OOM killer是通过/proc//oom_score这个值来决定哪个进程被干掉的。这个值是系统综合进程的内存消耗量、CPU时间(utime + stime)、存活时间(uptime – start time)和oom_adj计算出的,消耗内存越多分越高,存活时间越长分越低。总之,总的策略是:损失最少的工作,释放最大的内存同时不伤及无辜的用了很大内存的进程,并且杀掉的进程数尽量少。  另外,Linux在计算进程的内存消耗的时候,会将子进程所耗内存的一半同时算到父进程中。

最后还是说一下使用需要注意的事项:

1、内存首先要足够基本进程的正常运行,以防被无缘无故kill

2、要对tomcat的设置进行优化,尤其是对内存的控制

注解是什么,如何使用注解,为什么使用注解

注解是什么

注解,可以看作是对 一个 类/方法 的一个扩展的模版,每个 类/方法 按照注解类中的规则,来为 类/方法 注解不同的参数,在用到的地方可以得到不同的 类/方法 中注解的各种参数与值。

怎么使用注解

1、自定义注解类

注解类上方的注解各种含义,看这个链接http://www.cnblogs.com/peida/archive/2013/04/24/3036689.html

2、枚举类

3、注解使用

通过注解获取到了具体的配置信息,并且打印,那么注解的功能就说完了

以上演示的是类型注解,方法注解则修改注解类中

@Target(ElementType.TYPE)  ===> @Target(ElementType.METHOD)   按照以下方法调用即可

为什么用注解

优点

配置文件

1,集中管理对象和对象之间的组合关系,易于阅读

注解

1,开发速度快

2,编译期间容易发现错误的出处

缺点

配置文件

1,开发速度相对较慢;

2,编译时很难检查出错误,运行中的错误很难定位,调试难度较大。

注解

管理分散,基本每个类上都有;


一个小特性

注解有类似继承这样的机制,A.java 实现了spring的@Component可以被注入到spring容器,但如果自定义的注解有spring的@Component注解的话,那么在具体使用这个自定义注解时候将不需要原本使用的spring注解,具体事例如下:

这是原本应该有的注解形式,一个自定义注解以及一个spring的注解

如果自定义注解 拥有spring的@component注解

那么在具体使用时,可以忽略之前的注解

以上观点为自我理解的结果,如有错误,请指正!~