这段时间一直在思考分布式事务的实现，一开始的思路总是停留在应用层面上，后来经过查看相关资料才知道，要支持分布式事务得需要数据库的支持，也就还是回到了数据库层面，另外在Java里面结合javax.sql扩展包里面使用两段提交协议能轻松支持分布式事务。 后来自己结合之前做过的一些项目，发现原来之前实现的功能已经利用消息队列
今天看到一个技术群里面聊到事务与并发的关系，发现好多开发者的理解不一样，想把自己再工作中遇到的例子在这里呈现出来，以告诉大家自己所理解的事务与并发，先简单说下流程吧！ 我们公司的A,B系统通信使用的是ActiveMQ，主要是订单状态的通信，之前遇到的一个问题是A系统通过一个事务修改了订单的状态要通过ActiveMQ通知B系统，B系统收到
package test; import java.io.UnsupportedEncodingException; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.util.Arr
从事Java多线程开发的程序员来说，了解Java的线程池实现原理是必不可少的，以下将会结合Java线程池代码来说明它的实现原理，首先，我们要思考：线程池的表现形式线程池里面的线程什么时候创建线程池里面的线程什么时候结束或者该不该结束线程池的实现原理说道Java线程池就不得不说ExecutorService接口和Executors类了，从源码上来看Executo
之前公司有个同事离职，然后我交接了他的一些项目，其中有一个日志项目，主要就是业务部门调用Client往服务器上传日志文件，这个过程使用了netty，问题很奇怪大致如下：1：一天中总有那么几个文件会上传失败报的异常信息是：20:08:03.937] WARN DefaultPromise - An excepti
最近花了一周的时间，写了一个可扩展的RPC框架，服务可扩展，协议可扩展，目前只有实现netty的服务，协议分别实现了hessian和java自带的序列化协议，后续有时间灰更新其他的服务以及协议，传输协议使用自己自定义的协议前四个字节表示长度，后一位字节表示协议内容长度，后面的字节表示协议，在后面的就是个序列化的Object了，废话不多说了，项目地址：开源中国地址：htt
之前在InfoQ看到一篇关于java重排序的一篇文章，觉得里面有些知识写得太绝对了，于是想通过实际程序来说明一下： 关于java重排序，这里就不做介绍了，我们知道JVM底层封装了与OS的交互，它内部有自己的一套类似于OS的内存模型，程序重排序的设计思路基本上是来源于OS跟硬件层面的设计。下面直接入正题吧！ &nbs
今天再看JDK源码的时候看到了String类的不同版本的实现方式的不同，主要是substring这个方法，JDK6里面的实现方式是：很明显可以看到，调用String对象的substring方法后指向的对象地址并没有发生改变，只是改变的是偏移量，这样的话在GC阶段就有可能造成内存泄露了。 还好查了一下资料JDK7解决了这个问题，于是赶紧查看了JDK7
并发编程模型的分类在并发编程中，我们需要处理两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的
在很多情况下，访问一个程序变量（对象实例字段，类静态字段和数组元素）可能会使用不同的顺序执行，而不是程序语义所指定的顺序执行。编译器能够自 由的以优化的名义去改变指令顺序。在特定的环境下，处理器可能会次序颠倒的执行指令。数据可能在寄存器，处理器缓冲区和主内存中以不同的次序移动，而不是 按照程序指定的顺序。例如，如果一个线程写入值到字段a，然后写入值到字段b，而且b的值不依赖于a的值，那么，处理器就
之前在跑一个任务的时候，那个任务需要使用第三方的jar，关于这个jar可以再打包的时候嵌入到包中也可以查看hadoop-env.sh脚本里面有加载classpath的脚本语句：for f in $HADOOP_HOME/contrib/capacity-scheduler/*.jar; do if [ "$HADOOP_CLASSPATH" ];
最近一直在开发移动端的接口，在内部测试的时候发现这么个奇怪现象： 现象： 一部Android手机访问服务器响应没什么问题，当使用两部Android手机同时访问的时候会出现有一部手机访问不了接口的现象。 解决思路： 遇到这种问题首先想到的是使用
在Java里面，我们经常使用JSON格式的工具包对字符串或者对象进行解析，一般用得比较广泛的三种分别为：fastJson,jackJson,Gson，关于各个工具包的性能比较网络上比比皆是，在这里我只阐述在我本机环境下的测试结果，然后在根据结果对三种工具包进行一个解析，首先先贴代码：import java.util.Map; import org.c
本网站的博客将要迁移至： http://my.oschina.net/u/143244
从事网络编程的应该都知道传输层的主要协议是TCP/UDP，关于两者的区别网络上有好多资料这里就不多说介绍，然而数据的传输过程大都有个IO操作，因此就衍生出了BIO，NIO，AIO三大模型，关于这三者的区别本系列博客有介绍，欢迎大家参考并指正，本篇主要写基于Java实现的NIO编程模型的一些使用细节，欢迎正在使用NIO编程的朋友们出来讨论，希望起到一个抛砖引玉的效果。&n
由于公司之前使用的手机客户端推送服务是极光推送，给公司造成一年几十万的服务费，因此，公司决定开发自己的一套推送服务，初步的技术选型是：服务端：netty4 关于netty框架在我的下面的博客里面我整理了相关资料，本来还有一些关于mina的由于时间原因暂时没整理出来。 为了便于自己测试，自己动手实现了如何使用netty完成服务端
最近在看netty的源码，本来想写一些东西的，但是无意间看到了一个牛人写的一些有关netty的博客，感觉写得太好了，故对他的博客中有关netty的部分整理了一下放入了我的印象笔记中，现在把链接公开出来，希望对想学习netty的同学有所帮助:https://app.yinxiang.com/pub/topxiall/netty
JMS开源消息中间件有很多，本文对常见的几种进行了列举和简单比较，希望对MOM选型的个人和企业有所帮助。mom4jmom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.OpenJMSOpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现
最近在研究xampp协议的过程，于是找了开源的openfire与tigase的源码粗滤的阅读了一下,由于tigase目前的中文文档比较少，于是主要整理了有关tigase的一些资料供大家参考，由于文章比较多，这里只留下一个印象笔记的连接供大家阅读。https://app.yinxiang.com/pub/topxiall/tigase
0、引言： 之前在校招时，旁边的面试官问过这样一个问题：如何不在 main 函数里打印出一行字符串呢（也不允许在main里调用函数）？ 如果你不能回答上来没关系，看了本文你就会有了答案。其实 main 函数我们每天 coding 都会接触，但是不一定每个同学都了解或注意到它为什么要这么设计，为什么不能那么写？ 言 归正传，Main方法是我们学习Java编程语言时知道的第一个方法，你是否曾
1. jstat 这个命令对于查看Jvm的堆栈信息很有用。能够查看eden,survivor,old,perm等heap的capacity,utility信息 对于查看系统是不是有能存泄漏以及参数设置是否合理有不错的意义2. jstack 这个是用来查看jvm当前的thread dump的。可以看到当前J
1.为什么要分代 我们先来屡屡，为什么需要把堆分代？不分代不能完成他所做的事情么？其实不分代完全可以，分代的唯一理由就是优化GC性能。你先想想，如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而我们的很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，当GC的时候先把这块存“朝生
synchronized static
java设计模式 1:策略模式类图：2：单例模式类图：3：多例模式类图：4:工厂方法类图:5：抽象工厂模式类图：6：门面模式类图：7：适配器模式类图：8:模版方法模型类图：9：建造者模式类图：10:桥梁模式类图：11：命令模式类图：12:装饰模式类图：13:迭代器模式类图：14：组合模式类图：15：观察者模式类图:16：责任链模式类图：17：访问者模式类图：18：状态模式类
Java™ 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量。这两种机制的提出都是为了实现代码线程的安全性。其中 Volatile 变量的同步性较差（但有时它更简单并且开销更低），而且其使用也更容易出错。在这期的 Java 理论与实践 中，Brian Goetz 将介绍几种正确使用 volatile 变量的模式，并针对其适用性限制提出一些建议。
1.尽量在合适的场合使用单例 使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面 第一，控制资源的使用，通过线程同步来控制资源的并发访问 第二，控制实例的产生，以达到节约资源的目的 第三，控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信 - 2.尽量避免随意使用静态变
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
