george

            BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
            12 Posts :: 0 Stories :: 17 Comments :: 0 Trackbacks

          2009年12月7日 #

          spring注解使用了有一段時間了,現做幾個就簡單的記錄,具體是使用方式不用多說網上很多,這里便于記憶簡單整理一下。
          1.注入的屬性有2種方式
             1.1 @Autowired(按類型type注入)
             1.2 @Resource(按名字name注入),
              另:如果遇到重復使用@Qualifer標注別名
                     如果不需要某些屬性注入可以設置Autowired或resources的required屬性為false
          2.將bean納入spring容器有4種方式
              2.1 @Component(表示是spring容器中的bean,比較中立,沒有其他含義)
              2.2 @Controller ,@Service ,@Repository,這3種和@Compnent功能一樣,只是用于三層架構中的控制,業務及持久層。目前只是命名不同。
              另:@Scope可以定義bean的作用范圍。
          3.對于注解需要配置context:component-scan定義初始化容器掃描的目錄。
          <context:component-scan base-package="com.blog">
              
          <context:include-filter type="regex" 
                  expression
          ="com\.blog\.service\..*"/>
              
          <context:exclude-filter type="aspectj" 
                  expression
          ="com.blog.util..*"/>
          </context:component-scan>

          4.注釋配置和 XML 配置的適用場合

              4.1注釋配置不一定在先天上優于 XML 配置。如果 Bean 的依賴關系是固定的,(如 Service 使用了哪幾個 DAO 類),這種配置信息不會在部署時發生調整,那么注釋配置優于 XML 配置;反之如果這種依賴關系會在部署時發生調整,XML 配置顯然又優于注釋配置,因為注釋是對 Java 源代碼的調整,您需要重新改寫源代碼并重新編譯才可以實施調整。
              4.2如果 Bean 不是自己編寫的類(如 JdbcTemplate、SessionFactoryBean 等),注釋配置將無法實施,此時 XML 配置是唯一可用的方式。
              4.3注釋配置往往是類級別的,而 XML 配置則可以表現得更加靈活。比如相比于 @Transaction 事務注釋,使用 aop/tx 命名空間的事務配置更加靈活和簡單。
              4.4所以在實現應用中,我們往往需要同時使用注釋配置和 XML 配置,對于類級別且不會發生變動的配置可以優先考慮注釋配置而對于那些第三方類以及容易發生調整的配置則應優先考慮使用 XML 配置
          參考資料: 
          http://kdboy.javaeye.com/blog/419159
          http://www.ibm.com/developerworks/cn/java/j-lo-spring25-ioc/

          posted @ 2009-12-07 23:21 georgeliu 閱讀(723) | 評論 (0)編輯 收藏

          2009年8月18日 #

          在生產環境中tomcat內存設置不好很容易出現內存溢出。造成內存原因是不一樣的,當然處理方式也不一樣。
          這里根據平時遇到的情況和相關資料進行一個總結。常見的一般會有下面三種情況:
                  1.OutOfMemoryError: Java heap space
                  2.OutOfMemoryError: PermGen space
                  3.OutOfMemoryError: unable to create new native thread.
          對于前兩種情況,在應用本身沒有內存泄露的情況下可以用設置tomcat jvm參數來解決。(-Xms -Xmx -XX:PermSize  -XX:MaxPermSize)
          最后一種可能需要調整操作系統和tomcat jvm參數同時調整才能達到目的。

          第一種:是堆溢出。
                  在JVM中如果98%的時間是用于GC且可用的 Heap size 不足2%的時候將拋出此異常信息。
                  沒有內存泄露的情況下,調整-Xms -Xmx參數可以解決。
                  -Xms:初始堆大小 
                  -Xmx:最大堆大小 
                  但堆的大小受下面三方面影響:
                  1.相關操作系統的數據模型(32-bt還是64-bit)限制;(32位系統下,一般限制在1.5G~2G;我在2003 server 系統下(物理內存:4G和6G,jdk:1.6)測試 1612M,64為操作系統對內存無限制。)
                  2.系統的可用虛擬內存限制;
                  3.系統的可用物理內存限制。
                  堆的大小可以使用 java -Xmx***M  version 命令來測試。支持的話會出現jdk的版本號,不支持會報錯。
                   -Xms -Xmx一般配置成一樣比較好比如set JAVA_OPTS= -Xms1024m -Xmx1024m

          第二種:永久保存區域溢出
                  PermGen space的全稱是Permanent Generation space,是指內存的永久保存區域。這一部分用于存放Class和Meta的信息,Class在被 Load的時候被放入PermGen space區域,它和和存放Instance的Heap區域不同,GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理,所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤。這種錯誤常見在web服務器對JSP進行pre compile的時候。但目前的hibernate和spring項目中也很容易出現這樣的問題。http://www.javaeye.com/topic/80620?page=1 的帖子有討論的這個問題。可能是由于這些框架會動態class,而且jvm的gc是不會清理PemGen space的,導致內存溢出。
                  這一個一般是加大-XX:PermSize  -XX:MaxPermSize 來解決問題。
                  -XX:PermSize 永久保存區域初始大小
                  -XX:PermSize 永久保存區域初始最大值
                  這一般結合第一條使用,比如 set JAVA_OPTS= -Xms1024m -Xmx1024m  -XX:PermSize=128M -XX:PermSize=256M
                  有一點需要注意:java -Xmx***M  version 命令來測試的最大堆內存是 -Xmx與 -XX:PermSize的 和 比如系統支持最大的jvm堆大小事1.5G,那  -Xmx1024m  -XX:PermSize=768M 是無法運行的。
                  
          第三種:無法創建新的線程。
                  這種現象比較少見,也比較奇怪,主要是和jvm與系統內存的比例有關。
                  這種怪事是因為JVM已經被系統分配了大量的內存(比如1.5G),并且它至少要占用可用內存的一半。有人發現,在線程個數很多的情況下,你分配給JVM的內存越多,那么,上述錯誤發生的可能性就越大。
                  
                  產生這種現象的原因如下(從這個blog中了解到原因:http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html):

                  每一個32位的進程最多可以使用2G的可用內存,因為另外2G被操作系統保留。這里假設使用1.5G給JVM,那么還余下500M可用內存。這500M內存中的一部分必須用于系統dll的加載,那么真正剩下的也許只有400M,現在關鍵的地方出現了:當你使用Java創建一個線程,在JVM的內存里也會創建一個Thread對象,但是同時也會在操作系統里創建一個真正的物理線程(參考JVM規范),操作系統會在余下的400兆內存里創建這個物理線程,而不是在JVM的1500M的內存堆里創建。在jdk1.4里頭,默認的棧大小是256KB,但是在jdk1.5里頭,默認的棧大小為1M每線程,因此,在余下400M的可用內存里邊我們最多也只能創建400個可用線程。

                  這樣結論就出來了,要想創建更多的線程,你必須減少分配給JVM的最大內存。還有一種做法是讓JVM宿主在你的JNI代碼里邊。

          給出一個有關能夠創建線程的最大個數的估算公式:

                  (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads

                  對于jdk1.5而言,假設操作系統保留120M內存:
                  1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
                  1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
                  在2000/XP/2003的boot.ini里頭有一個啟動選項,好像是:/PAE /3G ,可以讓用戶進程最大內存擴充至3G,這時操作系統只能占用最多1G的虛存。那樣應該可以讓JVM創建更多的線程。
                  因此這種情況需要結合操作系統進行相關調整。

          因此:我們需要結合不同情況對tomcat內存分配進行不同的診斷才能從根本上解決問題。

          參考資料(從這些資料中受益良多):
          http://www.javaeye.com/topic/80620?page=1
          http://ggmm.blog.sohu.com/117545379.html
          http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html
          http://www.wujianrong.com/archives/2006/12/javalangoutofmemoryerror_permg.html


          posted @ 2009-08-18 00:28 georgeliu 閱讀(14148) | 評論 (13)編輯 收藏

          2009年7月25日 #

          memcached是目前比較不錯的緩存。是一種集中式可以分布式部署的。現在許多大型的網站(facebook,豆瓣等)都使用memcached作為提高網站性能的重要的一環。
          最近在一個項目中用到了它感覺不錯,下面提供一些不錯的資源。
          Memcached相關資源:
          官方網站:http://www.danga.com/memcached/
          Java client:http://www.infoq.com/cn/articles/memcached-java 
          不錯的中文資源:http://tech.idv2.com/2008/08/17/memcached-pdf/ (如果要了解memcached細節這個不錯)
          windows memcache安裝:http://www.fcicq.net/wp/?p=160 


          posted @ 2009-07-25 23:55 georgeliu 閱讀(223) | 評論 (0)編輯 收藏

          2009年5月3日 #

          最近想做一個動態的圖標,類似于iphone中的信息圖標,圖片上可以動態的顯示通知信息的數目。
          因此就想到的水印效果,將一個默認的背景圖片和數字合成。

          下面的這篇文章可以大大這個目的:
          http://javaeyetianjin.group.javaeye.com/group/topic/8527
          但缺點也很明顯,圖像會有一定程度的失真。
          BufferedImage image = new BufferedImage(wideth, height,
               BufferedImage.TYPE_INT_ARGB);
          可能在圖片的處理過程中將像素打包成整數造成的。
          目前還沒找到比較好的方案。

          http://www.aygfsteel.com/Alpha/archive/2007/08/20/138171.html
          這個處理還是有點失真。
          posted @ 2009-05-03 17:10 georgeliu 閱讀(526) | 評論 (0)編輯 收藏

          2009年4月1日 #


          最近在了解google map的一些接口,無意間接觸了flex,
          發現一個flex學習網站(http://www.airia.cn)很不錯.
          其中有一個欄目是一周學會FLEX應用開發 視頻教學,里面的視頻很清晰,使用英文講的,發音很標準,基本可以聽懂,聽不懂下面還有翻譯,是個flex學習和英語聽力練習的好東東。





          posted @ 2009-04-01 00:11 georgeliu 閱讀(368) | 評論 (1)編輯 收藏

          2009年3月31日 #

          google總是能夠給人帶來驚喜,昨天推出了挑歌功能感覺不錯。

          可以根據不同的節奏,聲調和音色來搜索歌曲,可以根據自己的心情來選擇不同個歌曲。
          而且他的泡泡展示也很特別,很不錯。


          posted @ 2009-03-31 22:32 georgeliu 閱讀(242) | 評論 (0)編輯 收藏

          2009年3月22日 #

          昨天參加了磨坊組織的2009年深圳百公里徒步活動。我和花花走了體驗組的3段,從梧桐山到大梅沙共計38km。(體驗組路程共49km要走的玫瑰海岸)

          之前在磨坊上找的路線圖,從水庫上方開始走。




          和上面一樣,不過是地形圖。

          行程:
          早上6點起床,做26路到世界之窗,在坐地鐵到門診部,好不容易擠上了211(這個才是起點站的第二站,車子已經滿了,可見人多),經過一路小堵8:55才到梧桐山。也就是體驗組的起點。由于之前沒有報上名,也不談簽到了,直接就開路了。


          這個是體驗組出發點,人頭攢動,參選這次活動的人很多,報名的有2000人左右,從實際的情形看至少5000以上。
          我們9點鐘開始出發。


          這是在第一段遇到的,可能是這次參加活動中年齡最小的了。呵呵,他還有簽到卡。



          第一段路上還有一出塌方,看起來有點危險。



          11點到達第一簽到點(鹽田檢查站),里程13km,速度還可以。

          這個小朋友一路碰到4次,還算有緣,他的體力不錯。

          修整了40min,11:40開始第二段

          第二段是盤山公路比較累,偶爾有一些捷徑。這個照片是由于相機沒有完全打開時照的,看起來比較詭異。


          呵呵,這種休息方式效果不錯。


          2:15到了東部華僑城的茶溪古修整了半小時。


          這段路上看到了參賽寵物。這個狗狗很漂亮。


          3:20到了第二簽到點,山海大關,里程16km(總里程29km)。


          一般報名的一路上會有4灌紅牛補給,分別設在不同的簽到點。俺們由于沒有報上名,沒能享受到這個待遇。

          這里修整了半個小時,3:50開始出發。

          下一個終點是大梅沙,可能是由于第二段路程太辛苦,我已經感覺到腿有點不適了。下了山后步子已經邁不開了。
          好不容易慢慢拖到大梅沙。

          6:00到了大梅沙,里程9km(總里程38km)

          這個時候簽到點已經沒人了,看看時間,和自己的狀態,還有回來的坐車問題,我還是決定量力而行,結束了這段厲程。

          今天一覺醒來,好像殘廢了一樣,發現從腰一下沒有不酸不疼的地方,步子已經邁不開了。
          到網上查了有沒有緩解辦法:
          這種叫延遲性肌肉酸痛癥。一般在運動鍛煉后24小時內出現,24~72小時內達頂點,5~7天后疼痛基本消失。
          處理方法:
          可對酸痛的局部肌肉進行熱敷按摩;口服維生素C;針灸和電療也有一定作用.不做治療,5~7天后癥狀也會消失。

          不過總體來所,這次徒步活動還是不錯的體驗。


          posted @ 2009-03-22 23:58 georgeliu 閱讀(297) | 評論 (1)編輯 收藏

          2009年3月19日 #

          關注springside已經有一段時間,
          最早是從2.0版本開始的,現在已經到了3.1.2了。
          ss給我的感覺是從新鮮到興奮到失望。這兒發點牢騷。
          主要體現在下面幾點;
          1.springside項目的延續性不好
          ss2到ss3.1.2隨著版本號的增加功能確越來越小。做的一些demo演示越來越不實用。
          很懷念書店的demo,這個例子可以所是讓ss經過了一個實踐的檢驗,里面的技術細節考慮的要比現在的miniservice,miniexample要周全的多。
          我喜歡ss一方面是因為他的新鮮的架構組合和新技術指導性,另一方很大程度上是因為這個demo,他讓我看到了新架構帶來的生產力,實在的東西。
          而現在你在從springside官方網站下載SpringSide 2.0 RC1 all in one,下來運行一下看看,沒有半天到一天的時間更不不可能跑起來。這個里面使用maven來管理jar包,使用ant來調用,遺憾的是springside原先建立的私有lib Repository已經消失了,在這個項目中依賴的包非常多,有些是可以在公共的Repository找到的,這部分到好辦直接加入公共的Repository地址就可以了,而有以部分是經過springside封裝或重新打包的這些包何處去尋,那只好把這一部分屏蔽掉了,保證項目的運行。原來引入這個maven工具是為了很方面明晰的找到依賴的包,這下倒好反而成了絆腳石。要理清楚里面的關系,還是要一點時間的。這個就是項目不延續造成的。
          那有人就奇怪了,說你為什么不用最新的版本,而這也是我的苦衷,現在的最新版本倒是很輕量,把這些東西全砍掉了,只留下了一些miniexample,很難有進一步的更細節一點的指導,而且這些東西沒有經過一些實際項目的檢驗,可能還是會在細節上有所欠缺。就像一開始ss被封裝成像ruby一樣類似自動crud功能,而這個想法固然很cool但在實際應用中還是一個花架子,有很多不周全的地方,如果對基類不是很了解的情況下很難使用,反而沒有自己寫的明晰快速。

          2.定位不明晰
          ss2到ss3.12像是走了兩個極端,一個功能非常多(包括 jms,mail,jbossrules,lucene,compass,acegi,cxf,jbpm,activemq),一個一下瘦身太厲害基本減完了。
          雖然在后續可開發計劃中會陸續的補充,但是和ss2相比波動太大,而沒有在ss2基礎上過度過來,好像是另起爐灶的感覺。
          現在再想想ss的定位, 
            SpringSide是以Spring Framework為核心,提供Pragmatic的企業應用開發開源Kickstart。
            定位愈加清晰,不再企圖做一個RoR/Gails式的框架,只做主流選型組合的編程模式總結。
            SpringSide2.0的末期有點繁雜與失控,何寶榮說:不如我們從頭來過
          這里是Pragmatic(實用的),難道和ss2相比就ss3會更使用,技術更新這是肯定的,新技術當然可以吸引一部分眼球,但一旦使用了ss后更希望是項目上的指導。而如果只是些miniweb在項目上遇到的問題是很難依靠這個來解決的,感覺這會傷了許多ss fans的心。
          定位愈加清晰,不再企圖做一個RoR/Gails式的框架,只做主流選型組合的編程模式總結。這一點我認同
          SpringSide2.0的末期有點繁雜與失控,何寶榮說:不如我們從頭來過   ss2確實比較復雜,但是里面也不乏經典的東西,很多地方都可以為實際項目所借鑒。重頭來過這個會傷了我們,如果安版本持續下去哪怕版本慢一些,這樣不好嗎,重頭來過,你是要多ss用戶負責的。(貌似現在svn中2.0的源碼已經沒了)
          這里說一些題外話:
          在現在的互聯網發展速度非常快,在互聯網公司基本使用的都是動態語言,他們更敏捷,java在web的敏捷方面是如何優化也不能和他們相比的。而什么公司會用ss這類的東西來搭建企業應用呢,一般都一些集團公司的信息系統或門戶,而不是互聯網公司,如果互聯網公司用java做主營業務,那大部分都沒有飯吃(當然不排除一些特例),而這些集團公司更需要的是穩定,不過是功能和性能上的穩定,更重要的是技術上的穩定,因為他們打部分是以流程和業務為核心,如果使用動態語言去創新獲得良好的用戶體驗,但技術變化過快,在人員流動的情況下企業的業務很容易收到影響。而作為一個信息規劃人員,一般都會考慮使用一種相對穩定的技術,因為系統延續性,和信息的集成和流動才是最重要的,作為一個業務支撐部門。有句話說的好,我們需要創新,但應該是持續創新,而不是破壞性創新。因此在這些用戶群體才是最需要ss的,而不是要把ss搞和動態語言一樣輕量。如果ss在這方面當然是項目更深入更細節的問題上給于指導,那是最好不過了,bookstore的demo就是一個不錯的列子(當然還是有一些問題,比如在acegi的acl上還要進一步細化,等等)。而不是像現在的miniweb把我們領到ss里,然后撒手不管了。

          說了這么多,沒別的意思,希望springside更好。剛才出社會沒多久,可能有些地方視野還沒達到,這里只是說說我的想法。有不對的地方多多包含。
          posted @ 2009-03-19 00:49 georgeliu 閱讀(1822) | 評論 (2)編輯 收藏

          2009年3月18日 #


          關于這個內容javaeye已經有不錯的例子了
          http://jnotnull.javaeye.com/blog/275327

          在這個例子的基礎上我想說一一些需要注意的地方。
          1.重建索引和增量索引
          IndexWriter writer = new IndexWriter(directory,analyzer,rebuild,new IndexWriter.MaxFieldLength(200000));

          只需要在構造IndexWriter的時候設置rebuild值就可以了
          當rebuild設為true的時候:就會刪除原來的索引,重建索引文件
          當rebuild設為false時:表示增量索引,是在原來索引文件的基礎上增加新的索引內容,當然第一次沒有索引文件的時候必須先重建索引生成索引文件。

          在lucene2.4中不使用Field.Index.TOKENIZED而是使用Field.Index.ANALYZED,表示要對這個field進行分詞
          if(article.getArticleId()!=null)
              doc.add(
          new Field(Fields.FIELD_ARTICLEID,article.getArticleId(),Field.Store.YES,Field.Index.NOT_ANALYZED));
          if(article.getTitle()!=null)
              doc.add(
          new Field(Fields.FIELD_TITLE,article.getTitle(),Field.Store.YES,Field.Index.ANALYZED));
          當然這里的Fields.FIELD_ARTICLEID是自定義的類變量

          2.分頁檢索

          ScoreDoc[] hits = searcher.search(query,null,startIndex+perPage,new Sort(new SortField(Fields.FIELD_CHECKTIME,SortField.AUTO,true))).scoreDocs;
          int numTotalHits = searcher.maxDoc();//hits.length;
          int endIndex = Math.min(numTotalHits,startIndex + perPage);
          使用searcher.maxDoc()取出搜索的總記錄數,使用search(query,null,startIndex+perPage,new Sort(new SortField(Fields.FIELD_CHECKTIME,SortField.AUTO,true))).scoreDocs取出當前一頁的索引記錄(這個是2.4的新用法,可以獲得更高的性能),new Sort(new SortField(Fields.FIELD_CHECKTIME,SortField.AUTO,true)))來處理索引結果的排序。
          Document doc =searcher.doc(hits[i].doc);
          String title1 
          = doc.get(Fields.FIELD_TITLE);
          使用searcher.doc(hits[i].doc)取出索引的具體記錄

          3.高亮顯示
          SimpleHTMLFormatter simpleHTMLFormatter = new SimpleHTMLFormatter("<b><font color='red'>""</font></b>");
          Highlighter highlighter 
          = new Highlighter(simpleHTMLFormatter,
                              
          new QueryScorer(query));           
          highlighter.setTextFragmenter(
          new SimpleFragmenter(bestMatchSize));
          if (title1 != null) {
              TokenStream tokenStream 
          = analyzer.tokenStream(Fields.FIELD_TITLE,
                                  
          new StringReader(title1));
              highLightTitle 
          = highlighter.getBestFragment(tokenStream,title1);
          }
          new SimpleHTMLFormatter("<b><font color='red'>""</font></b>")構造高亮顯示的樣式。
          highlighter.setTextFragmenter(new SimpleFragmenter(bestMatchSize))設置顯示索引內容的最大字符數,相當于自動抽取含有關鍵的摘要。


          當然這個只是簡單索引和檢索過程。
          還有一些其他工作要做:
          1.索引的過程就是查詢的過程,需要把沒有索引的文章查詢出來進行索引,完畢有要打上標記。這里面就要為文章擴展索引標記,建立一些文章查詢。
          2.將索引操作加入調度定時執行,這個用quartz就可以了。



          posted @ 2009-03-18 21:48 georgeliu 閱讀(1628) | 評論 (0)編輯 收藏

          2009年3月17日 #

          呵呵,一年一度的深圳百公里要到了,以前就聽說比較好玩,今年打算體驗一下。
          就在磨坊上找找攻略。
          【活動線路】  
          蛇口海上世界---望海路---后海路---東濱路---沙河西路---濱海路---濱河路---紅嶺路---深南路---新秀村---羅沙路---仙湖公園---大望村---梧桐山邊防線---鹽田檢查站---東部華僑城---梅沙路口--大梅沙---溪沖---終點:玫瑰海岸

          【路況描述】  
          1、蛇口海上世界---紅嶺路(第1簽到點,里程約22KM)
          路況:  
          路 面良好,大部分人行道都完好,只有在望海路部分地段缺失。由后海路轉東濱路,建議過斑馬線,走路北的人行道,方便轉上沙河西路的人行道。由沙河西路轉濱海 路,建議走紅樹林公園里面的道路,可以看看夜晚的海邊,走公路邊沒有很好的人行道。從濱海路往紅嶺路走,一路有數個立交橋,請大家注意走橋洞,安全第一。 在赤尾天橋附近,有幾家食店的水準不錯,吃吃腸粉很正點。到了紅嶺路人行天橋就是第一個簽到點。

          2、紅嶺路---梧桐山村(第2簽到點,里程約23公里)
          路況:
          紅嶺路右轉上深南路,沿著深南路的人行道一直走到新秀村,沿途有部分地段修地鐵,請注意安全,新秀村可以補給一些水和食品。新秀村走羅芳路轉羅沙路,沿人行道一直到仙湖人行天橋,過了人行天橋沿路由仙湖植物園正門進入,仙湖植物園需要憑簽到卡、義工卡進入,車輛盡量不要進入,在仙湖植物園里面走寶巾路出仙湖植物園北門,沿路一直到大望村梧桐山邊防線路口。

          3、梧桐山村---鹽田檢查站(里程約13公里)  
          路況:
          平坦的青石板路,環境幽美,在全段線路中,有兩個地方有道路維修,請大家務必注意安全

          4、鹽田檢查站---山海大關(第3簽到點,里程約16公里)  
          路況:  
          沿盤山公路上行,經三洲塘水庫,東部華僑城云海谷、茶溪谷、茵特拉根小鎮路段,過三洲田水庫路段,到達山海大關簽到點。走這段路的風景就無須形容了,自己走慢些,好好享受。
            
          5、山海大關---大梅沙(第4簽到點,里程約9公里)  
          路況:  
          一路風景不錯,路面較窄,注意來往車輛。簽到點在大梅沙麥當勞門口。

          6、大梅沙---玫瑰海岸(長城海灘度假中心前行300米)(終點,里程約11公里)
          路況:
          海岸公路路面收窄彎多,不時有車輛經過,需非常謹慎小心。在長城海灘度假中心旁邊就是玫瑰沙灘,很多人在拍婚紗照片。

          當然第一次參加,要量力而行,我就準備去體驗組混混。
          【活動線路】
          梧桐山村---梧桐山邊防線---鹽田檢查站---東部華僑城---梅沙路口--大梅沙
          這段風景也不錯,大約37km,搞個8個多小時估計能拿下。
          主要是感受一下氣氛。

          簽到指引  

          本屆百公里共設置6個簽到點
          編號        簽到點名稱                     簽到截止時間
            1          蛇口海上世界                   3月20日21:00--22:30(A組簽到)
            2          紅嶺路(原任我行門口)       3月20日23:00--3月21日2:00
            3          梧桐山                           3月21日2:00--9:00(B組6:00--9:00開始簽到)
            4          山海大觀                        3月21日4:00--15:00
            5          大梅沙                           3月21日5:00--17:00
            6          玫瑰海岸                        3月21日9:00--21:00     

          這里主要關注一下裝備
          一、裝備   
          個人裝備 :鞋、襪、護膝、舒適的T恤及短褲、適合1日行程的小型輕便背包或水袋式背囊、登山杖、反光物、頭燈、手電、小量的藥物、輕便雨衣、高能量的食品及個人用品。可公用的東西帶一套既可,例如每隊一個小藥箱。  
          1、背包:好的背負系統很重要。裝包要平穩四正;不裝任何不必要的東西。  
          2、鞋子:最好輪換使用兩雙不同質地、不同鞋墊的徒步鞋或運動鞋。大一號的在尾段時穿著會較為舒適。登山鞋重,鞋底硬,公路長距離徒步不宜選擇登山鞋。
               長距離平地穿越,必然造成腳掌的極度疲勞。如果配備兩雙不同質地、不同鞋墊的鞋(如輕便跑鞋、徒步鞋、運動鞋),每隔一小時換鞋行走,并經常改變行走方式(行走、小跑結合),輪換腳掌受力點,整個腳掌受力更均勻,并調動腿部更多的肌肉群參與運動,必可減緩疲勞和疼痛,可以徒步更遠的路

               新鞋容易引致腳部不適,刺激水泡形成,因此正式參加活動時,最 好穿著練習時穿過的鞋。
               鞋帶要系緊,使鞋子包腳良好。 鞋底較薄可以加多一雙鞋墊或穿厚一點的襪子。 一般穿底厚有彈性運動鞋較好,登山鞋較重底硬,走久了易起水泡。很多人走不完百公里主要原因是鞋子沒選好腳起水泡而放棄。穿上厚的棉襪子可以減少腳與鞋底的磨擦,減少起水泡的機會。
               有經驗的毅行者建議在穿襪前在足趾背上涂上適量 Vaseline ointment (凡士林)膏,或用 Micropore tape (醫生膠布)把腳趾個別分開包扎,或嘗試用橡皮膏和泡漠雙面膠貼于足底
          3、襪子:厚棉襪。 以減低起水泡的機會。要帶備用, 多換幾次,能保持足部干爽,可預防水泡。  
          4、綁腿:能防止血脈下積而引起的漲疼,小腿不容易感到酸累。(這個就不用了)
          5、護膝:可拆式護膝,不定期地使用,不用時可以拆下。  
          6、護踝:如果只穿一雙低幫的徒步鞋,護踝很有必要。  
          7、登山杖: 減輕你雙腿的負擔,尤其是登高時。 (這個就不用了)
          8、柔軟的擦汗毛巾。
          9、要戴遮陽透氣的帽子、防曬霜。
          10、衣服:建議內褲選擇不磨擦大腿根的四角內褲 ,有透氣排汗性能的更好。根據活動性質和天氣狀況,選擇合適的衣物及備用。
            
          二:食物   
          1、 1、  在徒步(運動)途中,因胃腸消化功能自然減弱,所以不宜食用肉類等高脂肪高蛋白不易消化的食品。 碳水化合物是供給人體主要能量的營養物質,易消化,并能迅速釋放能量。所以應補充以碳水化合物為主的粥、米飯、粉、面、饅頭等谷類食品和蔬果、運動飲料等 易消化食品。  
          2、早餐、中餐可在路邊餐廳就餐。中途過多過雜的各式各樣的飲料,會使徒步人員感到腸胃不適。運動飲料、葡萄糖水、鹽水和適量的涼茶足矣。  
          3、吃了容易口渴的食物不要帶。包括:味道重的,辛辣的。  
          4、不要帶過多的水、食物,能在路上補充的就不帶。全程基本有路邊店可補給。注意要帶咸菜等補充鹽分、礦物質的食品。
          5、盡可能少食多餐,以保持穩定的能量供應,并可避免多食少餐所引起的胃部飽脹。沿途吃一些干果、餅干,間中吃一只香蕉。

          交通指引:
          梧桐山村
          211路:三島中心總站--梧桐山村 運營時間:梧桐山村6:30-22:00 建設路6:30-23:00


          鹽田關
          85路:鹽田檢查站--德興花園(清水河) 運營時間:6:30-21:30
          358路:航母世界--龍崗 運營時間:6:30--19:30
          380B線:龍華新圍村--小梅沙 運營時間:05:30--21:30

          大梅沙公交路線:
          J1:海上世界-大梅沙 運營時間:冬季7:00-20:00,夏季6:30-21:00
          1路觀光巴士:大梅沙-白石州: 運營時間:待查
          53路:東部華僑城總站--梅林檢查站 運營時間:夏季6:30—21:00冬季6:30—20:00
          308路:布吉總站--大梅沙總站 運營時間:6:30--21:30
          239路:航母世界--大梅沙總站 運營時間:7:00-19:00
          242路:梅林一村--大梅沙總站 運營時間:夏季 6:30-22:00 冬季 6:30-21:00  


          嘎嘎,看樣子準備的差不多了,明天去迪卡儂采購點裝備,再約上幾個哥們就成了。





          posted @ 2009-03-17 23:57 georgeliu 閱讀(928) | 評論 (0)編輯 收藏

          主站蜘蛛池模板: 赣榆县| 东阳市| 雷山县| 三门县| 滦平县| 隆化县| 乳源| 康乐县| 东方市| 大名县| 山西省| 新宁县| 绥德县| 宝山区| 乡城县| 罗平县| 左云县| 柳林县| 焉耆| 商丘市| 桂林市| 台前县| 厦门市| 文成县| 永吉县| 米林县| 德保县| 建德市| 鹤庆县| 明光市| 罗城| 京山县| 手游| 汨罗市| 麻栗坡县| 龙口市| 浦县| 丘北县| 河间市| 洪泽县| 台前县|