nginx提示地址或端口被占用解决

今天在启动nginx 的时候遇到如下的错误

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] still could not bind()

nginx也没有启动进程

[root@iZ25dgob05vZ /]# ps -ef|grep nginx

root     12150 12079  0 10:20 pts/0    00:00:00 grep nginx

kill也不能停掉进程

[root@iZ25dgob05vZ /]# killall -9 nginx

nginx: 没有进程被杀死

找了N多答案,都是说是端口被占用,但是各种解决方法无效可尝试以下操作:

1、检查80端口被什么程序占用

命令:fuser -n tcp 80

[root@iZ25dgob05vZ /]# fuser -n tcp 80

80/tcp:               7588

删除对应端口

[root@iZ25dgob05vZ /]# kill -9 7588

重新启动nginx

[root@iZ25dgob05vZ /]#  service nginx restart

Stopping nginx:                                         [FAILED]

Starting nginx:                                            [  OK  ]

JVM编码设置说明

今天服务器发现一个问题,部分中文显示正常,部分中文显示乱码。

简单访问一下,发现服务器解析中文参数没有问题,说明tomcat的编码utf-8已配置。

然后一琢磨,认为是源文件出现了编码问题。结果发现本地显示没问题,只有服务器有问题,那这下这个问题就有意思了。

经过排查,发现服务器端端catalina.sh 里少配置了 file.encoding ,导致解析出现乱码。

思考一下,发现还是有些不对, 为什么本地运行没问题,calalina.sh 配置文件中也没有配置编码,结果不乱码,服务器就乱码了呢?

 

满心欢喜的去查看服务器的默认编码,结果是 utf-8。。。

没有证明自己的预期,预期的结论是,tomcat jvm 没有设置编码,则采用系统的默认编码

由于还有很急的事情,日后再来补全这个测试。

悲观锁与乐观锁

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

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

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

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

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

sql server 注意事项

sql 函数使用注意事项:

sql 查询 使用函数count avg 等,查询数据库时,如果输入order by 则必须同样将函数中的字段进行分组(group by)

例如:

错误的写法:select count(0) from es_sellback_list where type=? AND tradestatus=? order by id

正确的写法:select count(0) from es_sellback_list where type=? AND tradestatus=? group by id order by id

或者 select count(0) from es_sellback_list where type=?

否则会报异常“ORDER BY 子句中的列 “‘cloum’ 无效,因为该列没有包含在聚合函数或 GROUP BY 子句中。

SQLServer分页必须order by 如果不包涵order by 自动id 降序,否则异常

在使用我们的page时,用到分页,如果要分页的表没有id 字段,那么需要手动添加一个order by cloum,否则异常

除非另外还指定了 TOP 或 FOR XML,否则,ORDER BY 子句在视图、内联函数、派生表、

sqlserver要求,没有指定TOP,那么要求不可以使用ORDER BY,因为排序是消耗资源的

 

服务器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的设置进行优化,尤其是对内存的控制

javashop v6.2 或将移除组件的component.xml文件,采用注解代替

链接

注解说明:移步 == 》 http://www.javamall.com.cn/blog/archives/311

首先说明一下已有组件的原理:

❤️在系统启动,spring加载时,我们判定一个即将实例化到spring容器中的对象否实现组件接口,如果实现则将其写入组件上下文(ComponentContext)的静态变量集合中,并且加载component.xml文件,生成ComponentView(组件视图)和PluginVIew(插件视图)

❤️自定义的监听器(EopContextLoaderListener)执行时,启动组件。根据ComponentView和PluginView正确生成可以正确调用插件的插件桩

修改后的逻辑

❤️在系统启动,spring加载时,我们判定一个即将实例化到spring容器中的对象否实现特定接口,如果实现 组件借口(IComponent) 则将其写入组件上下文(ComponentContext)的静态变量集合中,如果实现了插件接口(IPlugin)则将其写入插件上下文(PluginContext)

❤️自定义的监听器(EopContextLoaderListener)执行时,获取组件上下文中所有的组件,循环遍历从插件上下文中获取到组件对应的插件集合,根据每个组件和插件的注解,映射出正确的ComponentView(组件视图)和PluginVIew(插件视图)。随后,启动组件,根据ComponentView和PluginView正确生成可以正确调用插件的插件桩。

注解类讲解:

插件注解

CustomPlugin(自定义插件注解)

 插件名称 public String name() default “默认插件”;

 组件 public String component() default “组件id”;

 插件 public String plugin() default “插件id”; 

 执行优先级(保留字段 控制执行顺序) public int sort() default 10;

  插件桩集合 public String[] bundle() default “”;

CustomComponent(自定义组件注解)

 组件名称 public String name() default “默认组件”;

 组件id public String beanid() default “”;

 版本 public String version() default “1.0″;

 javashop版本 public String javashop_version() default “3.0.0″;

 作者 public String author() default “javashop”; 

描述 public String description() default “默认描述”;

属性字段基本和component.xml的配置具体参数没什么区别, 所以修改为注解的形式没有大的改动,只是更改了生成 ComponentView和PluginView的方式。

注解使用

在组件插件具体的类上,声明注解即可。

以上是对注解方式的组件的具体使用解释,接下来讲解连带的其它变更

1、组件加载

ComponentLoader(组件加载)在bean实例化之前的方法中,加入了插件上下文(PluginContext)的注册。

新增的插件上下文主要包含一个静态Map类型,key存组件的beanid,value存该组件的插件集合。

2、组件注册

ComponentContext(组件上下文)的注册组件方法中原本加载组件视图的方法被移除

3、组件启动

EopContextLoadListener(Eop上下文启动监听器)中,组件启动前,获取组件上下文中所有的组件视图,然后执行组件加载视图方法。(也就是在组件注册时的方法被延后执行)

随后执行原本的组件启动方法。

*********************************************主要修改部分************************************************

ComponentContext组件上下文核心方法loadComponent修改,为了兼容老版本的组件机制,这里对Bean是否声明了组件注解进行判定:

如果没有声明,那么按照传统的方法获取component.xml生成组件插件视图。

如果有声明,则获取注解信息进行组件和插件视图的生成。

*********************************************************************************************************

为什么组件机制使用注解实现

spring用注解的方式来管理容器中bean的关系,是所有人看的到到优点,使用注解之前,采用在xml中配置文件的繁琐程度不言而喻。使用注解唯一的缺点不外乎是管理松散,不能概括的了解组件、插件和插件桩的关系。但是只要项目结构足够合理,我相信这个问题是可以避免的。

抛开这些不说,作为一个程序员,喜欢看起来可以装X的代码,抛弃xml配置文件才用注解在个人看来是一个提升逼格的方法。哈哈哈哈

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

注解是什么

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

怎么使用注解

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注解

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

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

关于ajax请求未完成响应直接刷新导致走ajxa error事件问题解决

问题描述

浏览器ajax请求未完成响应,就刷新页面导致ajax执行ajax的error方法,造成一些不必要的错误提示

方法1:async : false

在ajax 函数中 加入 属性 async:false,即可
属性 async 默认值为 true
当async:false为同步,在这个Ajax请求将整个浏览器锁死,
只有ajax请求多url返回响应,才可以执行其它操作。
当async: true 时,ajax请求是异步的。如果有多个请求的话,就会一起发出一起响应。