java读书心得 篇1
首选很感谢Joshua Bloch写的这本书，当然更感谢我们的司令翻译。至少目前我看到的100页的内容，基本没发现翻译很别扭的地方，包括错别字也没有发现，至少没有影响到我对书中内容的理解。再次感谢。
在后面的读书心得里，我会根据我的个人理解，将书中的各个知识点逐个和大家分享。 书中的一些观点我也不是完全赞同的，呵呵(估计是我的水平不够，呵呵呵)。
我们先看全书第一个问题：考虑用静态工厂方法代替构造器。
也就是，不再使用 new 这种方式来获得一个类的实例，而是通过工厂方法获得。
优点：
1 有名字
这个我体会还是比较深的，在JDK里，我见过一个类的最多的构造器数量，有16个。大家可以看看 Java.math.BigDecimal 这个类就知道了。
就算一个类的构造器有4个左右，我想你很可能在使用的时候会极其注意，不要选错了到底是用哪一个。
所以，如果能提供一个很好命名的方法来实现构造类，确实是一个不错的主意，比如
BigDecimal.getInstanceFromString(...); 我想这个名字虽然有点垃圾，但要表达的意思确实异常的明确。
在一些第三方的库里面，这种情况更加突出。我许多时候不得不看看API文档，来区分我的那个int参数到底是使用三个参数的构造器，还是使用四个参数的构造器。因为他们太像了。
2 可以单例
这个就不用说了，你可以在方法里干你要做的任何事情，而new绝对会给你一个新的实例。
3 可以返回任何子类型。
这个对于系统的扩展是很有用处的。new 已经决定了你肯定要这个类，而静态方法却可以修改，不一定肯定返回你方法所在的类，可以在必要时替换为一个子类。
4 代码简便
这点我体会不深，呵呵
不过这个写法我确实经常用
List list = new List;
后面的那个List里面的 String就是一个例子吧。不过我倒是不是很在意这个，因为我很喜欢这样写了。
下面这个例子看上去确实不错。呵呵!
[java] view plain copypublic class Test extends Thread {
public static void main(String args) {
Test te = Test.newInstance;
}
public static Test newInstance {
return new Test;
}
}
java读书心得 篇2
寒假里，我最开心的是和爸爸妈妈一起去新华书店购买各种
图书，让各种书籍陪我度过整个假期。
今天，我就从众多阅读的书籍中，向大家推荐我我最喜欢的一本童话书——《鼹鼠的月亮河》。同学们不妨也找时间，静下心来，仔细阅读，相信会有很多有收获。
这本有趣的童话书讲述是主人翁鼹鼠米加一家的故事。他们住在月亮河一带，米加是这大家庭里最小的一个孩子。他又瘦又黑；他爱幻想，爱思考，爱发明创造；他不喜欢爸爸为他选择的人生道路。于是，他决定离开家乡，闯荡世界，为童年伙伴女鼹鼠尼里发明洗衣机。在经受各种磨难后，他渐渐长大，终于设计出洗衣机，实现了他发明洗衣机的梦想。
看完这本书后，我想我们每个人都应该有理想，要对未来充满信心，还要为实现理想付出不懈的努力的决心。做一个勤思考，爱动脑的人。因为只要坚持，就一定能成功。
java读书心得 篇3
注：框架可以用word菜单中的 “视图/文档结构图” 看到
j2ee模式
value object(值对象) 用于把数据从某个对象/层传递到其他对象/层的任意java对象。
通常不包含任何业务方法。
也许设计有公共属性，或者提供可以获取属性值的get方法。
jsp
1.jsp的基础知识
__
_____ | directive (指令)
| |-- scripting (脚本)
jsp -------| |__ action (动作)
|
|_____template data ：除jsp语法外，jsp引擎不能解读的东西
1)在jsp中使用的directive(指令)主要有三个：
a) page指令
b) include指令
c) taglib指令
在jsp的任何地方，以任何顺序，一个页面可以包含任意数量的page指令
2)scripting(脚本)包括三种类型
a) ;
b) ;
c) ;
3)action(动作)
标准的动作类型有：
a) ;
b) ;
d) ;
e) ;
f) ;
g) ;
h) ;日记300字
1. 注释： ;
;
2. ;
session可以不赋值，默认为true,如果session=”false”,则在jsp页面中，隐含的变量session就不能使用。
3. 请求控制器结构(request controller)
也被称之为jsp model 2 architecture
这种途径涉及到使用一个servlet或一个jsp作为一个应用程序或一组页面的入口点。
为创建可维护的jsp系统，request controller是最有用的方式之一。
不是jsp，而是java类才是放置控制逻辑的正确的地方。
请求控制器的命名模式为: controller.jsp
请求控制器类的命名模式为: requestcontroller
2.jsp中的javabean
jsp三种bean的类型
1) 页面bean
2) 会话bean
3) 应用bean
大多数的系统会使用一个会话bean来保持状态，而对每一个页面使用一个页面bean 来对复杂的数据进行表示。
页面bean是一个模型，而jsp是一个视图。
3.custom tag
bean是信息的携带者，
而tag更适用于处理信息。
标记库包含一个标记库描述符(tld)和用于实现custom tag的java类
在翻译阶段，jsp容器将使用tld来验证页面中的所有的tag是否都被正确的使用。
标记处理程序只是一个简单的适配器，而真正的逻辑是在另一个类中实现的，标记处理程序只是提供了一个供其他的可复用的类的jsp接口
servlet
1.servletconfig
一个servletconfig对象是servlet container在servlet initialization的时候传递给servlet的。
servletconfig包涵 servletcontext 和 一些 name/value pair (来自于deployment descriptor)
servletcontext接口封装了web应用程序的上下文概念。
2.会话跟踪
1) session
当一个client请求多个servlets时，一个session可以被多个servlet共享。
通常情况下，如果server detect到browser支持cookie，那么url就不会重写。
2) cookie
在java servlet中，如果你光 cookie cookie = new cookie(name,value)
那么当用户退出browser时，cookie会被删除掉，而不会被存储在客户端的硬盘上。
如果要存储 cookie，需加一句 cookie.setmaxage(200)
cookie是跟某一个server相关的，运行在同一个server上的servlet共享一个cookie.
3) url rewriting
在使用url rewriting来维护session id的时候，每一次http请求都需要encodeurl
典型的用在两个地方
1) out.print(“form action=\” ”);
out.print(response.encodeurl(“sessionexample”));
out.print(“form action=\” ”);
out.print(“method = get>;”);
2) out.print(“
;
out.print(response.encodeurl(“sessionexample?database=foo&datavalue=bar”));
out.println(“\” >;url encoded ;”);
3.singlethreadmodel
默认的，每一个servlet definition in a container只有一个servlet class的实例。
只有实现了singlethreadmodel，container才会让servlet有多个实例。
servlet specification上建议，不要使用synchronized，而使用singlethreadmodel。
singlethreadmodel(没有方法)
保证servlet在同一时刻只处理一个客户的请求。
singlethreadmodel是耗费资源的，特别是当有大量的请求发送给servlet时，singlethreadmodel的作用是使包容器以同步时钟的方式调用service方法。
这等同于在servlet的service方法种使用synchronized.
single thread model一般使用在需要响应一个heavy request的时候，比如是一个需要和数据库打交道的连接。
2. 在重载servlet地init( )方法后，一定要记得调用super.init( );
3. the client通过发送一个blank line表示它已经结束request
而the server通过关闭the socket来表示response已结束了。
4. 一个http servlet可以送三种东西给client
1) a single status code
2) any number of http headers
3) a response body
5. servlet之间信息共享的一个最简单的方法就是
system.getproperties.put(“key”,”value”);
6. post和get
post：将form内各字段名称和内容放置在html header内传送给server
get: ?之后的查询字符串要使用urlencode，经过urlencode后，这个字符串不再带有空格，以后将在server上恢复所带有的空格。
get是web上最经常使用的一种请求方法，每个超链接都使用这种方法。
7. web.xml就是web applicatin 的deployment descriptor
作用有：组织各类元素
设置init param
设置安全性
8. request dispatcher用来把接收到的request forward processing到另一个servlet
要在一个response里包含另一个servlet的output时，也要用到request dispatcher.
9. servlet和jsp在同一个jvm中，可以通过serveltcontext的
setattribute( )
getattribute( )
removeattribute( )
来共享对象
10. 利用request.getparameter( )得到的string存在字符集问题。
可以用 strtitle = request.getparameter(“title”);
strtitle = new string(strtitle.getbytes(“8859-1”),”gb2312”);
如果你希望得到更大得兼容性
string encoding = response.getcharacterencoding;
//确定application server用什么编码来读取输入的。
strtitle = new string(strtitle.getbytes(encoding),”gb2312”);
xml
1.xml基础知识
1. 一个xml文档可以分成两个基本部分：
首部( header )
内容( content )
2. xml名字空间规范中指定：
xml文档中的每一个元素都处在一个名字空间中;如果没有指定的名字空间，缺省的名字空间就是和该元素相关联的名字空间。
3. a document that is well-formed obeys all of the rules of xml documents (nested tags, etc.)
" if a well-formed document uses a document type definition (more on these in a minute), and it follows all the rules of the dtd, then it is also a valid document
4. a tag is the text between the ;
" an element is the start tag, the end tag,and everything (including other elements) in between
5. 标签( tags ) 实际上包含了“元素”( elements ) 和 “属性”( attributes )两部分。
用元素( elements )来描述有规律的数据。
用属性( attributes ) 来描述系统数据。
如果你有一些数据要提供给某个应用程序，该数据就可能要用到一个元素。
如果该数据用于分类，或者用于告知应用程序如何处理某部分数据，或者该数据从来没有直接对客户程序公开，那么它就可能成为一种属性。
6. cdata (读作：c data ) c是character的缩写。
.xml.sax.reader
/|\
org.xm.l.sax.xmlreader
/|\
org.apche.xerces.parsers.saxparser
2.webservice
2.1 webservice的基本概念
webservice是一种可以接收从internet或者intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。
这种技术允许网络上的所有系统进行交互。随着技术的发展，一个web服务可以包含额外的指定功能并且可以在多个b2b应用中协作通讯。
web服务可以理解请求中上下文的关系，并且在每一个特定的情况下产生动态的结果。这些服务会根据用户的身份，地点以及产生请求的原因来改变不同的处理，用以产生一个唯一的，定制的方案。这种协作机制对那些只对最终结果有兴趣的用户来说，是完全透明的。
uddi
在用户能够调用web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件。所以，我们需要一种方法来发布我们的web服务。
uddi (universal description, discovery, and integration) 是一个主要针对web服务供应商和使用者的新项目。uddi 项目中的成员可以通过uddi business registry (ubr) 来操作web服务的调用，ubr是一个全球性的服务。
web服务供应商可以在ubr中描述并且注册他们的服务。
用户可以在ubr中查找并定位那些他们需要的服务。
uddi是一种根据描述文档来引导系统查找相应服务的机制。
uddi包含标准的“白皮书”类型的商业查询方式，
“黄皮书”类型的局部查找，以及
“绿皮书”类型的服务类型查找。
uddi利用soap消息机制(标准的xml/http)来发布，编辑，浏览以及查找注册信息。它采用xml格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。
wsdl
对于商业用户来说，要找到一个自己需要使用的服务，他必须知道如何来调用。
wsdl (web services description language) 规范是一个描述接口，语义以及web服务为了响应请求需要经常处理的工作的xml文档。这将使简单地服务方便，快速地被描述和记录。
以下是一个wsdl的样例：
targetnamespace=""
xmlns:tns="" (5)(6)(7)(8)(9)(10)(11)(12)(13)(14)(15)
xmlns:xsd1=""
xmlns:soap=";
xmlns=";>;
xmlns=";>;
type="tns:stockquoteporttype">;
transport=";/>;
soapaction=""/>;
;my first service;
它包含了以下的关键信息：
消息的描述和格式定义可以通过xml文档中的;和; 标记来传送。
; 标记中表示了消息传送机制。 (e.g. request-only, request-response, response-only) 。
; 标记指定了编码的规范 。
; 标记中表示服务所处的位置 (url)。
wsdl在uddi中总是作为一个接口描述文档。因为uddi是一个通用的用来注册wsdl规范的地方，uddi的规范并不限制任何类型或者格式描述文档。这些文档可能是一个wsdl文档，或者是一个正规的包含导向文档的web页面，也可能只是一个包含联系信息的电子邮件地址。
现在java提供了一个 java api for wsdl (jwsdl)规范。它提供了一套能快速处理wsdl文档的方法，并且不用直接对xml文档进行操作，它会比jaxp更方便，更快速。
soap
当商业用户通过uddi找到你的wsdl描述文档后，他通过可以simple object access protocol (soap) 调用你建立的web服务中的一个或多个操作。
soap是xml文档形式的调用商业方法的规范，它可以支持不同的底层接口，象http(s)或者smtp。
之所以使用xml是因为它的独立于编程语言，良好的可扩展性以及强大的工业支持。之所以使用http是因为几乎所有的网络系统都可以用这种协议来通信，由于它是一种简单协议，所以可以与任何系统结合，还有一个原因就是它可以利用80端口来穿越过防火墙。
soap的强大是因为它简单。soap是一种轻量级的，非常容易理解的技术，并且很容易实现。它有工业支持，可以从各主要的电子商务平台供应商那里获得。
从技术角度来看，soap详细指明了如何响应不同的请求以及如何对参数编码。一个soap封装了可选的头信息和正文，并且通常使用http post方法来传送到一个http 服务器，当然其他方法也是可以的，例如smtp。soap同时支持消息传送和远程过程调用。以下是一个soap请求。
post /stockquote http/1.1
host: permission,java.io.reflect.reflectpermission,java.lang.security.securitypermission,以便加强先前所列出的编程限制。
许多ejb容器没有加强这些限制，他们希望ejb组件开发者能遵守这些编程限制或者是带有冒险想法违背了这些限制。违背这些限制的ejb组件，比标准方法依赖过多或过少的安全许可，都将很少能在多个ejb容器间移植。另外，代码中都将隐藏着一些不确定的、难以预测的问题。所有这些都足以使ejb组件开发者应该知道这些编程限制，同时也应该认真地遵守它们。
任何违背了这些编程限制的ejb组件的实现代码在编译时都不能检查出来，因为这些特点都是java语言和j2se中不可缺少的部分。
对于ejb组件的这些限制同样适用于ejb组件所使用的帮助/访问(helper/access)类，j2ee应用程序使用java文档(jar)文件格式打包到一个带.ear(代表enterprise archive)扩展名的文件中，这个ear文件对于发送给文件部署器来说是标准的格式。ear文件中包括在一个或多个ejb-jar文件中的ejb组件，还可能有ejb-jar所依赖的库文件。所有ear文件中的代码都是经过深思熟虑开发的应用程序并且都遵守编程限制和访问许可集。
未来版本的规范可能会指定通过部署工具来定制安全许可的能力，通过这种方法指定了一个合法的组件应授予的许可权限，也指定了一个标准方法的需求：如从文件系统中读文件应有哪些要求。一些ejb容器/服务器目前在它们的部署工具中都提供了比标准权限或多或少的许可权限，这些并不是ejb1.1规范中所需要的。
理解这些约束
ejb容器是ejb组件生存和执行的运行期环境，ejb容器为ejb组件实例提供了一些服务如：事务管理、安全持久化、资源访问、客户端连接。ejb容器也负责ejb组件实例整个生命期的管理、扩展问题以及并发处理。所以，ejb组件就这样寄居在一个被管理的执行环境中--即ejb容器。
因为ejb容器完全负责ejb组件的生命期、并发处理、资源访问、安全等等，所以与容器本身的锁定和并发管理相冲突的可能性就需要消除，许多限制都需要使用来填上潜在的安全漏洞。除了与ejb容器责任与安全冲突的问题，ejb组件还意味着仅仅聚焦于商务逻辑，它依赖于ejb容器所提供的服务而不是自己来直接解决底层的系统层的问题。 3 4 5 6 7 8 9 10 11 12 13 14 15
可能的问题
通常，ejb组件在容器之间的移植不可避免地与如下问题相关：
1.它需要依靠的受限制的特点在特定ejb容器中没有得到加强。
2.它需要依靠的非标准的服务从容器中可获得。
为了保证ejb组件的可移植性和一致的行为，你应该使用一个具有与java2平台安全
策略集相一致的策略集的容器来测试ejb组件，并且其加强了前述的编程限制。
总结
ejb组件开发者应该知道这些推荐的关于ejb组件的编程限制，明白它们的重要性，并且从组件的稳定性和可移植性利益方面考虑来遵循它们。因为这些编程限制能阻止你使用标准的java语言的特点，违背了这些编程限制在编译时不会知道，并且加强这些限制也不是ejb容器的责任。所有这些原因都使你应很小心地遵守这些编程限制，这些限制在组件的中已经成为了一个条款，并且它们对于建造可靠的、可移植的组件是非常重要的。
2. 优化ejb
entity bean为在应用程序和设计中描述持久化商业对象(persistent business objec ts)提供了一个清晰的模型。在java对象模型中，简单对象通常都是以一种简单的方式进行处理但是，很多商业对象所需要的事务化的持久性管理没有得到实现。entity bean将持久化机制封装在容器提供的服务里，并且隐藏了所有的复杂性。entity bean允许应用程序操纵他们就像处理一个一般的java对象应用。除了从调用代码中隐藏持久化的形式和机制外，entity bean还允许ejb容器对对象的持久化进行优化，保证数据存储具有开放性，灵活性，以及可部署性。在一些基于ejb技术的项目中，广泛的使用oo技术导致了对entity bean的大量使用，sun的工程师们已经积累了很多使用entity bean的经验，这篇文章就详细阐述的这些卡发经验：
*探索各种优化方法
*提供性能优化和提高适用性的法则和建议
*讨论如何避免一些教训。
法则1：只要可以，尽量使用cmp
cmp方式不仅减少了编码的工作量，而且在container中以及container产生的数据库访问代码中包括了许多优化的可能。container可以访问内存缓冲中的bean,这就允许它可以监视缓冲中的任何变化。这样的话就在事物没有提交之前，如果缓存的数据没有变化就不用写到数据库中。就可以避免许多不必要的数据库写操作。另外一个优化是在调用find方法的时候。通常情况下find方法需要进行以下数据库操作：
查找数据库中的纪录并且获得主键
将纪录数据装入缓存
cmp允许将这两步操作优化为一步就可以搞定。[具体怎么做我也没弄明白，原文没有具体阐述]
法则2：写代码时尽量保证对bmp和cmp都支持
许多情况下，ejb的开发者可能无法控制他们写的bean怎么样被部署，以及使用的container是不是支持cmp.
一个有效的解决方案是，将商业逻辑的编码完全和持久化机制分离。再cmp类中实现商业逻辑，然后再编写一个bmp类，用该类继承cmp类。这样的话，所有的商业逻辑都在cmp类中，而持久化机制在bmp中实现。[我觉得这种情况在实际工作中很少遇到，但是作者解决问题的思路值得学习]
法则3：把ejbstore中的数据库访问减小到最少。
如果使用bmp,设置一个缓存数据改变标志dirty非常有用。所有改变数据库中底层数据的操作，都要设置dirty,而在ejbstore中，首先检测dirty的值，如果dirty的值没有改变，表明目前数据库中的数据与缓存的一致，就不必进行数据库操作了，反之，就要把缓存数据写入数据库。
法则4：总是将从lookup和find中获得的引用进行缓存。(cache)
引用缓存对session bean和entity bean 都是适用的。
通过jndi lookup获得ejb资源。比如datasource,bean的引用等等都要付出相当大的代价。因此应该避免多余的lookup.可以这样做：
将这些引用定义为实例变量。
从setentitycontext(session bean使用setsessioncontext)方法查找他们。setentitycontext方法对于一个bean实例只执行一次，所有的相关引用都在这一次中进行查找，这样查找的代价就不是那么昂贵了。应该避免在其他方法中查找引用。尤其是访问数据库的方法：ejbload和ejbstore,如果在这些频繁调用的方法中进行datasource的查找，势必造成时间的浪费。
调用其他entity bean的finder方法也是一种重量级的调用。多次调用finder方法的代价非常高。如果这种引用不适合放在setentitycontext这样的初始化时执行的方法中执行，就应该在适当的时候缓存finder的执行结果。只是要注意的是，如果这个引用只对当前的entity有效，你就需要在bean从缓冲池中取出来代表另外一个实体时清除掉这些引用。，这些操作应该在ejbactivate中进行。
法则5:总是使用prepare statements
这条优化法则适用于所有访问关系数据库的操作。
数据库在处理每一个sql statement的时候，执行前都要对statement进行编译。一些数据库具有缓存statement和statement的编译后形式的功能。数据库可以把新的statement和缓存中的进行匹配。然而，如果要使用这一优化特性，新的statement要必须和缓存中的statement完全匹配。
对于non-prepared statement,数据和statement本身作为一个字符串传递，这样由于前后调用的数据不同而不能匹配，就导致无法使用这种优化。而对于prepared statement,数据和statement是分开传递给数据库的，这样statement就可以和cache中已编译的statement进行匹配。statement就不必每次都进行编译操作。从而使用该优化属性。