如今很多Java项目应该都采用Maven进行构建, 其依赖管理, 配置式工作原理使得项目构建也变得比较灵活统一。
基础, Maven基于XML进行配置, 其配置文件叫pom.xml, 如<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><artifactId>module-name</artifactId><packaging>jar</packaging><version>pacakge version</version><name>module-name</name><url>http://maven.apache.org</url><!-- jar包依赖管理--...阅读全文

最近做一个企业团购相关的项目, 这两天有人也提出了有关业务规则的一些东西, 特别一些有关营销的业务, 比如送积分, 送券这些。假如我们要搞一些营销活动,对一次性购买多少件或多少钱的用户送上一张面值不同的券, 放在平时, 可能马上就开个feature, 在下单后判断用户所支付的钱是否满足这个条件, 满足则送, 不满足就不送。但是, 要是现在希望更吸引用户, 我要降低门槛, 或增大面值, 难道又开个Hotfix改这段逻辑?似乎不是没有道理, 但是, 世间变化的东西太多, 我们人太难预料和把控, 那么如何去更好地认识这种问题呢?
这两天也想了又想, 到底要怎么才能更好地管理这些频繁变化的业务逻辑, 似乎自己想得太过于复杂, 或者想得不太清楚。现在想想, 似乎也有点点思路, 其实, 要把这些业务完全抽象出来是不可能的, 总不能拍拍屁股就让程序去执行一段逻辑了吧。
现在是这样想的: 我们自己还是要从代码业务中抽离出这些经常执行上述逻辑的地方,比如用户登录, 注册, 下单等。个人觉得我们要抽离的这些业务通常不会, 也不应该影响主逻辑, 比如送券, 不会送券没成功, 就不让用户下单吧, 这应该可...阅读全文

Happen-Before指的是两个操作之前的一种偏序关系，比如，操作A happen-before 操作B，那么操作A对于操作B是可见的(即操作A产生的影响会作用于操作B，如共享变量更新，消息发送，方法调用等)，记作hb(A, B)。
比如，下面的代码:1. i = 1; // T12. j = i; // T23. i = 2; // T3操作1, 2, 3分别在线程T1, T2, T3中执行，若有偏序关系hb(1, 2)，即T1的操作1对T2的操作2是可见的，那么，T2的操作2执行后，变量j的值一定为1(此时T3的操作3还未执行)，但若T3的操作3发生在操作1，2之间，就不能确定最终i的值是多少，因为操作3，2并没有偏序关系，因此操作3的结果有可能影响操作2，也有可能不会。
JMM中的happen-beforeJMM中已经规范出一些典型的hb关系，摘自周志明的<<深入理解Java虚拟机>>331页，也可查看官方JLS:1. 程序次序规则: 同一线程内，前面的动作hb后面的动作。
2. 管程锁定规则: 对于同一个锁，unlock()操作hb下一次lock()操作。
3. v...阅读全文

1. 多个线程: 当然得在多线程环境下。
2. 共享变量: 若不存在共享变量(即存在本地变量)，多个线程只能访问本地线程栈的数据。
3. 可变变量: 即使存在共享变量，但是该变量不可变(即初始化后，就不会更新状态)。
4. 写操作: 即使共享变量可变，但是多个线程不存在更新操作(仅读操作)，此时依然是线程安全的。

为什么有了上述条件成立后，就有可能出现并发问题归根结底，还是由于Java内存模型和硬件架构引起的，摘得一张好图，共赏之:类似这种情形，跑在CPU上的一个线程将这个共享对象读到CPU缓存中，然后修改了这个对象。只要CPU缓存没有被刷新会主存，对象修改后的版本对跑在其它CPU上的线程都是不可见的。这种方式可能导致每个线程拥有这个共享对象的私有拷贝，每个拷贝停留在不同的CPU缓存中。
而Java中volatile的作用就是，让线程从主内存中读取变量，当这个变量被修改时，总会被写会到主内存中，这样就能保证多个线程能看到共享变量最新的值了(Java同步块(synchronized)也能达到同样的效果)。Java锁锁在并发中，无疑是基础而直观重要的组件，是避免并发问题的好帮...阅读全文

2016 年 03 月 05 日java服务器利用线程技术响应客户请求已经很常见，这的确提高了服务器的响应处理能力，但通常服务器端并不会为每个客户端请求分配一个新的线程对象，在大量的客户端的请求下，这种处理方式将会创建大量的线程来处理请求，这对内存和CPU都是很不利的，于是需要一种更合理的线程技术，这就是线程池技术。在日常开发中，也或多或少会接触到线程池，比较Servlet容器处理浏览器请求的线程池，数据库连接池等，本文将理解一番JDK本身的线程池(ThreadPool)实现，与其他线程池相比，也会大同小异。
...阅读全文