分类目录: Java

Google Guava简介

看到Guava这个名字觉得有点怪怪的,于是搜索了一下,Google Java的合称。Guava工程包含了若干被Google的 Java项目广泛依赖 的核心库,例如:集合(collections)、缓存(caching)、原生类型支持(primitives support)、并发库 (concurrency libraries)、通用注解(common annotations)、字符串处理(string processing)、I/O 等等。 所有这些工具每天都在被Google的工程师应用在产品服务中。

项目信息
首页:https://code.google.com/p/guava-libraries/ 
并发编程网在对每一个主题的各个子类的介绍进行翻译并发表。这里转载目录。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.13- 8票) Loading ... Loading ... | 同时归档在:语言基础 | 标签: , |

Java 内存模型与线程规范——JSR133中文版

原文链接 译文链接   翻译:丁一   下载:JSR133中文版

本文是JSR-133规范,即Java内存模型与线程规范,由JSR-133专家组开发。本规范是JSR-176(定义了Java平台 Tiger(5.0)发布版的主要特性)的一部分。本规范的标准内容将合并到Java语言规范Java虚拟机规范以及Java.lang包的类说明中。本JSR-133规范将不再通过JCP维护和修改。未来所有对这些标准化内容的更新、修正以及说明都会出现在上述这些文档中。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.17- 6票) Loading ... Loading ... | 同时归档在:语言基础 | 标签: , , |

Java程序员应该知道的10个面向对象理论

本文由 ImportNew唐小娟 翻译自 Javarevisited。如需转载本文,请先参见文章末尾处的转载要求。

面向对象理论是面向对象编程的核心,但是我发现大部分Java程序员热衷于像单例模式、装饰者模式或观察者模式这样的设计模式,而并没有十分注意学习面向对象的分析和设计。学习面向编程的基础(如抽象,封装,多态,继承等)是非常重要的,而运用它们来设计干净的模块也同样重要。我也认识很多不同等级的程序员,他们没有听过这些面向对象理论,或者不知道某个设计理论有什么好处,或者如何在编码中使用这些设计理论。

我们起码要设计出高度一致而且松散耦合的代码。Apache和Sun的源代码就是学习Java面向对象理论的非常好的例子。JDK遵循了一些设计模式,譬如在BorderFactory中使用工厂模式,Runtime类中使用单例模式,java.io中的许多类中使用装饰者模式。如果你真的对Java编程感兴趣,请先阅读Joshua Bloch的Effective Java,正是他参与编写了Java API。另外两本我喜欢的关于设计模式的书还有,Kathy Sierra等编写的的Head First Design PatternHead First Object Oriented Analysis and Design。这些书帮助理解面向对象理论,并帮助我写出更好的代码。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.57- 7票) Loading ... Loading ... | 同时归档在:语言基础, 软件技术 | 标签: , , , , , , , , , |

一种常见的并发编程场景的处理

对于并发编程,大家想到总是多线程之间对等的临界资源竞争。然而经常会遇到下面这样的场景:

守护线程提供一个临界资源,多个子线程会并发改写该临界资源。大部分时候(99.9%的时间),主线程是不会干涉各个线程之间的竞争的,通常只要该临界资源自己内部处理好同步即可。但是偶尔主线程也会干预一下该临界资源,比如做一些统计,做一个快照,或者复制数据然后清空等。这个操作通常会耗时比较长,并且在此期间不希望有人改写临界资源。如果,主线程与各个子线程使用同样的锁或者synchronized同步,那么在主线程没有作该操作时,各个子线程之间会因为竞争而阻塞,这个阻塞开起来是没有必要的。

这里介绍一个利用volatile变量的特性解决该问题的方案。尝试在性能和数据保护上面达到最大平衡。Atomic变量是采用的寄存器(volatile)变量实现的。用两个变量标志map表当前的状态。而不必在后台线程和众多业务线程之间加锁或者同步,由于在多数情况下volatile变量的性能优于锁(Java 理论与实践: 正确使用 Volatile 变量)。这里只以map表举例,其他保证线程安全的数据结构也适用。

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 4票) Loading ... Loading ... | 同时归档在:多线程编程, 语言基础 | 标签: , |

关于Java中Random的一些使用细节

Random类相信大家都不陌生,但是必须掌握一些特定的细节才能在要求较高的场合用好该变量。这里分析一个多线程环境下Random的使用。

现在面临一个问题:有多个线程需要按照随机的方式取一个令牌,尽量让每个线程取得的令牌不一样,可以认为令牌就是一个数字,如1~100之内的一个整数。那么怎样实现能最好的解决这个问题呢?首先想到的是用一个同步的变量,使用一个getAndIncrement接口,这样每个线程调用这个接口时都能获得一个与其他同时访问该接口不一样的值。当然这不是本帖想要讨论的问题。本帖希望用随机数生成器的方式给每一个线程提供这个接口。

于是一位粗心的同学有了下面这样的接口:

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.86- 7票) Loading ... Loading ... | 同时归档在:多线程编程, 语言基础 | 标签: , , |

广度优先搜索解决“营救公主”问题

在之前的一篇文章(迷宫营救公主算法)中提供了一个半成品的解决方案,之所以说他是半成品,是因为首先选择的算法就不对,采用的是深度优先搜索,其次也没有真正的用对深度优先算法,走过的点应该标记为已经走过,而不应该重复遍历该节点。下面的文章对于广度优先和深度优先两种算法的解释非常到位。今天准备把这个问题再完整的用正确的算法解答一遍。

文章链接:【图论】广度优先搜索和深度优先搜索

就营救公主的问题而言,这里不再重复描述问题了,请点击这里查看题目分析:链接。这次选用广度优先算法来解决该问题。上面的算法介绍文章中对该算法已经分析得非常清晰了。先给解决本问题的算法伪代码:

这里每个节点有三种状态:

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 同时归档在:算法数据结构 | 标签: , , , , , |

JVM并发机制的探讨——内存模型、内存可见性和指令重排序

转自oschina

并发本来就是个有意思的问题,尤其是现在又流行这么一句话:“高帅富加机器,穷矮搓搞优化”。从这句话可以看到,无论是高帅富还是穷矮搓都需要深入理解并发编程,高帅富加多了机器,需要协调多台机器或者多个CPU对共享资源的访问,因此需要了解并发,穷矮搓搞优化需要编写各种多线程的代码来压榨CPU的计算资源,让它在同一时刻做更多的事情,这个更需要了解并发。

在我前一篇关于并发的文章http://my.oschina.net/chihz/blog/54731中提到过管程,管程的特色是在编程语言中对并发的细节进行封装,使程序员可以直接在语言中就得到并发的支持,而不必自己去处理一些像是控制信号量之类容易出错且繁琐的细节问题。一些语言是通过在编译时解开语法糖的方式去实现管程,但Java在编译后生成的字节码层面上对并发仍然是一层封装,比如syncrhonized块在编译之后只是对应了两条指令:monitorenter和monitorexit。更多的并发细节是在JVM运行时去处理的,而不是编译。这篇文章主要是针对JVM处理并发的一些细节的探讨。

JAVA内存模型

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 同时归档在:多线程编程 | 标签: |

一个明显的jetty-8大文件传输性能大幅降低问题分析

这个问题很早就分析、修改和验证过了,一直没有来得及总结整理。今天突然想起来了,首先用我那蹩脚的英语给jetty的维护团队提了一个问题单,在等待他们回复的同时,我也把我发现问题的过程分享一下。

问题单链接:https://bugs.eclipse.org/bugs/show_bug.cgi?id=415282

经过打断点和调试,发现如下调用占用了性能下降(相对于jetty7版本)的绝大多数处理耗时:

public class HttpOutput extends ServletOutputStream 
{
/* ------------------------------------------------------------ */
private void write(Buffer buffer) throws IOException
{
if (_closed)
throw new IOException("Closed");
if (!_generator.isOpen())
throw new EofException();

// Block until we can add _content.
while (_generator.isBufferFull())
{
_generator.blockForOutput(getMaxIdleTime());
if (_closed)
throw new IOException("Closed");
if (!_generator.isOpen())
throw new EofException();
}

// Add the _content
_generator.addContent(buffer, Generator.MORE);

// Have to flush and complete headers?

if (_generator.isAllContentWritten())
{
flush();
close();
}
else if (_generator.isBufferFull())
_connection.commitResponse(Generator.MORE);

// Block until our buffer is free
while (buffer.length() > 0 && _generator.isOpen())
{
_generator.blockForOutput(getMaxIdleTime());
}
}
}
具体的耗时消耗在:_generator.blockForOutput(getMaxIdleTime());
从函数名字都可以看出来,当网络繁忙时,会走到这个流程,在blockForOutPut中,首先会注册一个socket可写的事件,当该socket上面可以写数据时,通知当前业务线程,随后业务线程投入休眠。等待事件分发线程检查可读事件,并唤醒自己。这样在这个交互中不可避免的会损失部分数据传输性能,每一包数据虽然只会损失一点点性能,但是传输一个很大的文件时,就会发现这个损失的巨大,在10GE的网卡上面,数据传输的性能降低到了原来的1/10,这个影响太明显了。
 
那么问题到底出在哪里呢?
看下面的代码:
public class HttpGenerator extends AbstractGenerator
{
public void addContent(Buffer content, boolean last) throws IOException
{
if (_noContent)
throw new IllegalStateException("NO CONTENT");

if (_last || _state==STATE_END)
{
LOG.warn("Ignoring extra content {}",content);
content.clear();
return;
}
_last = last;

// Handle any unfinished business?
if (_content!=null && _content.length()>0 || _bufferChunked)
{
if (_endp.isOutputShutdown())
throw new EofException();
flushBuffer();
if (_content != null && _content.length()>0)
{
if (_bufferChunked)
{
Buffer nc=_buffers.getBuffer(_content.length()+CHUNK_SPACE+content.length());
nc.put(_content);
nc.put(HttpTokens.CRLF);
BufferUtil.putHexInt(nc, content.length());
nc.put(HttpTokens.CRLF);
nc.put(content);
content=nc;
}
else
{
Buffer nc=_buffers.getBuffer(_content.length()+content.length());
nc.put(_content);
nc.put(content);
content=nc;
}
}
}

_content = content;
_contentWritten += content.length();

// Handle the _content
if (_head)
{
content.clear();
_content=null;
}
else if (_endp != null && (_buffer==null || _buffer.length()==0) && _content.length() > 0 && (_last || isCommitted() && _content.length()>1024))
{
_bypass = true;
}
else if (!_bufferChunked)
{
// Yes - so we better check we have a buffer
if (_buffer == null)
_buffer = _buffers.getBuffer();

// Copy _content to buffer;
int len=_buffer.put(_content);
_content.skip(len);
if (_content.length() == 0)
_content = null;
}
}
}
 
问题出在下面这段代码上面:
// Handle the _content
if (_head)
{
content.clear();
_content=null;
}
else if (_endp != null && (_buffer==null || _buffer.length()==0) && _content.length() > 0 && (_last || isCommitted() && _content.length()>1024))
{
_bypass = true;
}
else if (!_bufferChunked)
{
// Yes - so we better check we have a buffer
if (_buffer == null)
_buffer = _buffers.getBuffer();

// Copy _content to buffer;
int len=_buffer.put(_content);
_content.skip(len);
if (_content.length() == 0)
_content = null;
}
我的理解,_bypass变量标志不使用缓存,直接将数据刷到客户端,如果这是jetty8的新增特性,那么也不应该是到外层再调用blockforoutput方法,而是直接flushbuffer即可。很明显这是一个bug,bypass的判断条件有误,_buffer为空,这是不使用缓存的条件,但是_buffer.length() == 0并不是该特性的条件,每一次初始化的时候都会默认操作_buffer使得_buffer.length() == 0。这样就导致了每一包数据都走进了blockforoutput流程。应该是一个明显的笔误,问题的修改方法即是去掉该不当的判断条件,只保留_buffer==null的判断。
 
同前面的jetty若干性能问题的分析一样,这个问题的分析也耗费了大量的时间和精力,最终是借助于比对jetty7和jetty8的代码和不停的加日志打点调试得出的。每一个问题的解决都是一段辛酸的故事。
| 1 分2 分3 分4 分5 分 (5.00- 18票) Loading ... Loading ... | 同时归档在:Jetty | 标签: , |

Java网络应用程序(Geronimo、Jetty)调试及问题定位方法简介

Java网络应用程序调试及问题定位方法简介

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 同时归档在:Geronimo, Jetty, 实用脚本 | 标签: , , |

迷宫营救公主算法

今天下班前在公司的技术题库中看到这道题目,思路很快就有了,递归遍历每一条可能的路径,然后找出最短的路径。回家把代码写出来了。发现算法效率实在是太低了,在矩阵较小的时候还好,当矩阵稍微大一点时根本算不过来,感觉复杂度像是O((N*M)^(N*M))这个数值太庞大了,也完全没有意义。公主等到花儿都谢啦。。

貌似这位同学的算法还不错,还没来得及研究,先做个链接:http://blog.csdn.net/joseph_1118/article/details/9390301

应付较小的矩阵下面的方法还是能蒙混过关的。先发到这里,后面再继续研究优化。题目和代码都在一起:

/**
* 公主被魔王抓走了,王子需要拯救出美丽的公主。他进入了魔王的城堡,魔王的城堡是一座很大的迷宫。
* 为了使问题简单化,我们假设这个迷宫是一个N*M的二维方格。迷宫里有一些墙,王子不能通过。王子只
* 能移动到相邻(上下左右四个方向)的方格内,并且一秒只能移动一步。地图由’S’,’P’,’.’,’*’
* 四种符号构成,’.’表示王子可以通过,’*’表示墙,王子不能通过;’S’表示王子的位置;’P’表示公主
* 的位置;T表示公主存活的剩余时间,王子必须在T秒内到达公主的位置,才能救活公主。如下图所示:
*/

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 9票) Loading ... Loading ... | 同时归档在:算法数据结构 | 标签: , |
返回顶部