2016年10月02日

ThreadPool JDK5

メモしとこ。

JDK5から使えるスレッドプールの実装。

スレッド管理のわずらわしさから開放される。
以下のサンプルはMachineクラスがたまにアホになり無限ループする。
たぶんjextractとjdmpviewの勉強用に作ったサンプルだったと思う。


import java.util.*;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class test
{
    public static void main(String[] argv)
    {
        ExecutorService threadPool = Executors.newFixedThreadPool(5);
        
        Collection<Callable<Void>> processes = new LinkedList<Callable<Void>>();
        for(int i=0 ; i < 5; i++)
        {
            final Machine m = new Machine(i);
                processes.add(new Callable<Void>() {
                    @Override
                    public Void call() {
                        m.exec();
                        return null;
                    }
                });
        }
        
        try {
            threadPool.invokeAll(processes);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            threadPool.shutdown();
        }
    }
}
続きを読む
posted by koteitan at 17:05| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年02月07日

[java]多重ループからの脱出

大昔のJDKでもできたっぽい。(;´Д`・・・

いままで多重ループの内側から一気に脱出しなければならないようなロジックを書く必要が無いぐらい
ちゃんとオブジェクト指向して書いていたからだ!!!! 

とでも思って慰めておくことにする。
Gotoみたいなもんじゃん・・。例外エラーロジックだとtry〜catchでいいやん。

書き方は分岐先頭or末尾にラベルを書く。(for、while、ifなどなど)

HOGE: for(int i = 0; i< max; i++)
{

}

とか

if(hoge > 0) { HAGA:

}
とか。

脱出には 

break HOGE;

とか

continue HAGA;

とか書く。

まぁ、知らなくてもおk。
3つも4つもループするなら普通はprivateメソッドになるやろ。( ´Д`)
posted by koteitan at 17:47| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月30日

[java]Dolphin!(4)

どこまで書いたかな・・。


//(3)String Switch
String str1="abcde";
switch(str1)
{
case "hoge":break;
case "huga":break;
case "abcde":System.out.println(str1);break;
}


キタ━━━━(゚∀゚)━━━━!!
もうこれでしょーもない private static final int とか Enumを作らなくてよいし、
ソース分析時に、このswitchの数字の意味はなんなんだ・・・、43だけスルーとかなんなんだ・・・。
コメントねーし、ぐぬぬぬぬ(`皿´;)とかも解決!

よし、まぁ待て。落ち着け。
内部ではEnumに自動変換してそうな予感がしてしょうがない。

でゅわ、jdの出番だ。


String str = "abcde";

Object localObject1 = str;
int k = -1;
switch (((String)localObject1).hashCode())
{
case 3208229:
if (((String)localObject1).equals("hoge")) k = 0; break;
case 3213991:
if (((String)localObject1).equals("huga")) k = 1; break;
case 92599395:
if (((String)localObject1).equals("abcde")) k = 2; break;
}

switch (k) {
case 0:
break;
case 1:
break;
case 2:
System.out.println(str);
}

文字列ハッシュでswitchかーって感想だけだと、味気ないので、もうちょっと|д゚)カンサツ

if(localObject1.equals("hoge")){
}else if(localObject1.equals("hoge")){
}else if(localObject1.equals("abcde")){
}
でも良さそうな気がせんでもないし、実際昔はこう書くしかなかった。
でも、先にハッシュだけ比較するほうが計算コストが低くなるので
こういう実装なんだと思う。コンパイル時に対象のハッシュも確定できるし。

つまり、String#equals() の実装見てくれればわかるんだが
比較は大きくわけて5ステップある。

(1)自分自身か?
(2)文字列のインスタンス?
(3)文字数一致?
(4)ハッシュ一致?
(5)文字列のコンペア

(4)の処理は初回のみ実行時計算@インスタンスなので、
JDK7の実装だとハッシュ一致時のみしかラベル文字のハッシュ計算は走らないが、
旧の実装だと必ず走ってしまう。また、(2)の処理は意外にコストが要る計算である。
文字列以外が来る可能性が_でもあるなら、しょうがないけど。

ということで涙ぐましいコスト最適化がかかっているために、こういった表記なんだと思うんだね。


posted by koteitan at 11:07| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月22日

[java]Dolphin!(3)

新しいコードスタイル(3)

これも細かいなぁ。(´-ω-`)

  //(3)ダイヤモンド演算子
  List list = new ArrayList<>();

Genericsの面倒なあの表記を宣言時は省略できます。
当たり前だよね、宣言してんだから、その型に決まってるわけで。

posted by koteitan at 10:37| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月21日

[java]仮想マシンの制限値

メソッド1クラス65535!
フィールド1クラス65535!
インターフェース65535!
メソッドサイズ64KB!

王将のCMのノリで覚えら・・・れるわけないわな。
まぁ、こんな制限に引っかかるClassがあるわけないのでしらんでも困らないがね。
もっと詳しく知りたい貴方は仮想マシン仕様の「4.10 java仮想マシンの制限」のところ参照。



posted by koteitan at 18:36| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月18日

[java]Dolphin!(2)

新しいコードスタイルその2。
その1も大した変更じゃなかったが、その2も大したものじゃない。
でも、便利。

(2)バイナリアン大歓喜

   int a2 = 0b00000111;

2進数表記ができます。
これで、ビット操作も直感的に書けます。

ビット操作要る局面が業務アプリであるかどうかは別として
ゲームとかだと結構使うと思うけど。
posted by koteitan at 13:27| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月17日

[java]Dolphin!(1)

まぁJDK7のコードネームなんだけどな。
5がtiger、6がMustang。虎、野生馬、ときてイルカ。( ′∇ソ ヨーワカラン このセンス。

project Coin 、プロジェクト小銭でコードの規約が若干変わってズボラ仕様が追加された。
なかなかいい感じのもあるしビミョーなのもあるけど、概ね好感触。
Javaが流行りだしたころに鳴り物入りで作ったシステムもそろそろライフサイクルを終えはじめ、
システム刷新や更新を考え出す企業さんとかもそこそこあるんではなかろうか。
まぁ、参考になればいいかなって程度で何回かに分けて紹介します。
小出しにして記事数稼ぐともいう。

(1)数値リテラルにアンダースコアが使えるようになった!
   これで桁数数えるのも楽だね! (*´д`;)

        int a1 = 1234_5678_9;

   もちろん浮動小数でもおkなので、

        float f1 = 1.23_45E5f;
        double d1 = 0x1234_567P-2;

   こんなんでもよい。
   またいくつ重ねてもいいので、極端な話

        int inoki = 0x1_____2______3______daaaa;

   ボンバイエも可能。業務コードで書いたらしばかれるから注意な。
   マジックナンバーとして使えなくもないが、まぁやめとくがよいでしょ。
posted by koteitan at 14:39| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月11日

[Java]keepalive

java でHTTPアクセスをするとき、まさかsocketから書くようなメンドイことはしまい。
HttpURLConnectionなり、HttpClientなりを使うと思う。
(Rawソケットを触りたいなら、すでに言語選定が間違っているしね)

このHTTPURLConnectionは結局はHTTPClientを内部で呼ぶんだけど
こいつにはkeepaliveがかかる。

制御するパラメータは以下のシステムプロパティ
---------------------------------------------

キープアライブの動作を制御するシステムプロパティーは次のとおりです。

http.keepAlive=
デフォルト: true

キープアライブ (持続) 接続をサポートすべきかどうかを示します。

http.maxConnections=
デフォルト: 5

任意の時点で接続先ごとにキープアライブを実行できる最大接続数を示します。

http://docs.oracle.com/javase/jp/6/technotes/guides/net/http-keepalive.html
---------------------------------------------
grepcode (http://grepcode.com/)からHTTP処理時の流れを追いかけてみると
URLスキーマから、処理すべきクラスを決定して適切なクラスをリフレクションしているようだ。
コード読んでいて気がついたんだけど
keepaliveの破棄はリアルタイムではなく、5秒固定のポーリングを行い、
その時点でタイムアウトしていれば破棄する、という処理だった。
よって、サーバー側から5秒以下のkeepalive要求が来たとしても
java側は最低5秒まではsocketを維持している。
(維持しているだけで使用はできないのでご安心を)

著作権的に該当箇所を引用していいかわからない(sunパッケージ内だから)ので
気になる人は上のサイトから自分で確認してくだしあ。

openJDKは原則GPLだけど一部例外アリとかそんなんだった気がするんだよな。
OSSはこういうライセンスがフリーなようでフリーじゃないような罠が結構あるんだよなぁ。

posted by koteitan at 15:12| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月08日

[java][python] singpath

これはなかなかクイズというか、初級学習の確認によいかもしれん。

singpath
https://itunes.apple.com/app/singpath-mobile/id567470737

英語なのがネックだけど。
posted by koteitan at 17:27| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年10月26日

java-DeCompiler

javaの逆コンパイラと言えば標準のjavapとかjadが有名ですが、
ジェネリックスとかがあるとうまく整形されないとか手に入りにくいとかいろいろあるですな。

http://java.decompiler.free.fr/?q=jdgui

このサイトから入手できる jd-gui.exe がなかなかGoodでして
jarファイルをそのまま逆コンパイルできるわ、階層的に辿れるわ
丸ごとjavaファイルを作れるわ、などといままでシェルとかでチマチマやってたのが
馬鹿らしくなるです。
おまけにジェネリックスとか列挙型もちゃんと理解するし、いい感じですよ。

※classやjarファイルを解析することははリバースエンジニアリングに相当するため、
 製品などのjarやclassの場合は禁止する旨がライセンスに記載されていることもあるので
 取り扱いは慎重に実施ください。
 何かあっても当方は一切関知しませんし責任も負いませんよ。
posted by koteitan at 18:27| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年02月08日

[java]sun.reflect.GeneratedSerializationConstructorAccessor の正体

sun.reflect.Generatedほげほげ などの解説

-これは何?



 reflectionを行うときの ByteCode Accessor


-は?



 アクセッサーには2種類あり、JNI AccessorとByteCode Accessor
 ご存知のようにJNI操作はコストが高いので、頻繁に呼び出されるとJNIからByteCodeへ昇格される
 そうすることで、reflectの動作を高速化させている。
 これが導入されたのはJRE1.4x以降



-このクラスをロードしたとか消したとかでまくるんだが、ぉぃい



reflectAPIの呼び出し単位で作成されてしまうので、フレームワークなんかを
使っているともう吐き気するぐらい作成される。
ClassオブジェクトなのでJVMのバージョンによってはHeapの中では厄介ものである
(フラグメント要因になる)。
だが安心してほしい。弱参照状態で作成され、参照は親のClassLoaderだけなので、
「使用中」でなければ破棄できる。
破棄されたものは、再びJNI Accessorからの出直しになる。



-それって、パフォーマンス元に戻るんじゃね?意味なくない?


パレートの法則。80:20の法則。

 GC対象になるようなAccessor = 未使用 =20%部分じゃない =パフォーマンスに影響を与えない

 パフォーマンスチューニングにおける大前提である。



-制御したいんだが



  -D sun.reflect.noInflation = false (default value is false)
  -D sun.reflect.inflationThreshold = 15 (default value is 15)

  noInfration =true は進化をやめよ、となり、デフォルトでbyteCodeAccessorが作成される
  よって、マッハになるかもしれないがsun.reflect.Generatedほげほげの数は増える

  inflationThreshold は進化までの回数。デフォルトでは15回呼ばれるとHot判定になりbyteCodeAccessorが作成される

  普通はこんなコアな設定はさわらんでよろしい。
  その前に直すべき箇所があるはずである。



参考リンク
https://www.ibm.com/developerworks/mydeveloperworks/blogs/738b7897-cd38-4f24-9f05-48dd69116837/entry/reflection_a_memory_viewpoint3?lang=ja
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
http://stackoverflow.com/questions/2971019/how-to-avoid-generatedserializationconstructoraccessor-problems
posted by koteitan at 11:23| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

[java]備忘録2012 JDK1.4.2の(以下略


ダークマターによるGCの誘発について
http://www-01.ibm.com/support/docview.wss?uid=swg21214654

IBMJDKにおけるIC(Incremental Compaction)について
http://www.ibm.com/developerworks/ibm/library/i-incrcomp/

IBMJDKが巨大オブジェクトをどのように扱うのか(LOAの説明)
http://www-01.ibm.com/support/docview.wss?uid=swg21236509

その他GCの動きの説明
http://www.nminoru.jp/~nminoru/java/cms/concurrent_mark_sweep.html#45


ヒープ圧縮(shrink)について
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1004853

IBMJDK1.4.2におけるComapction発生要因
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/topic/com.ibm.java.doc.diagnostics.142/html/id1156.html?path=0_5_7_2_5#id1156

※Reason8 transient heap云々Compactionは zOSのみでAIX/Linux/Win では発生
しない

posted by koteitan at 11:12| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

[Java]備忘録2012 JDK1.4.2のこまごま

kCluster と pCluster の説明
http://www.ibm.com/developerworks/jp/lotus/library/dm-0802tessarek/index.html#AS_4
http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.142%2Fhtml%2Fpinnedclusters.html
http://www.atmarkit.co.jp/fjava/rensai4/websphere03/websphere03_4.html
http://www-01.ibm.com/support/docview.wss?uid=swg21196072

JDK1.5からはこのkCluster枯渇によるヒープフラグメンテーションは発生しない。

巨大なメモリ要求を確認するには、ALLOCATION_THRESHOLD変数を設定する
(1.3.1SR10?、1.4.2SR4?)
1.5、1.6は別の変数(-Xdumpの設定で行う)
設定すると、少し負荷が上がる。

http://www-01.ibm.com/support/docview.wss?uid=swg21236523
posted by koteitan at 11:10| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年01月30日

[Java]-jar オプション

-jar オプションて便利じゃないですか、いちいちクラス名とかも
書かなくていいし、パッケージについても説明しなくていいし。

でもね、罠がありましてな。(今回これに気付くまでだいぶかかった(;´Д`))

CLASSPATHが効かない。

-cpとかが無効になる。
アッハッハ。

一応マニフェストファイルのClass-Path: エントリに書くことで回避はできるのだが、
そのjarファイルからの相対パスでかかなくてはならず、実行環境に依存してしまう。

いけてねーなぁ・・・。

http://java.sun.com/javase/ja/6/docs/ja/technotes/tools/windows/java.html#-jar

このオプションを使用すると、指定した JAR ファイルがすべてのユーザークラスのソースになり、ユーザークラスパスのほかの設定は無視されます。
posted by koteitan at 17:36| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2011年04月28日

[java]Excella -Core Tips(2)

@Objects 方式でパースする時に
プロパティのタグを打つとおもうわけよ。

サンプルのページでいうところのworkStartHour やworkContentsね。

これを「頭大文字で長め(8文字ぐらい)」にするとなぜかparse結果がnull。

こんなんわからんwこれも一個前のと同じくバグくさいが。
java beansの規約とかだったかなぁ。

setter/getterの名前は頭大文字でもOK(Eclipseとかだと自動で付くと思う)

まとめる。


・プロパティ名がABCDefgh とかは危険
・プロパティ名abcdefgなら、setter/getterは setAbcdefg()/getAbcdefg()

としておくと無難。Eclipseを怒らせ泣けばおkということだな。

これも半日なやんだんだぜ。
posted by koteitan at 14:34| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

[Java]ExcellaーCore Tipsメモ

あんまり情報無いよねぇ。
使われてないのかな。
ちょっとわかりにくかったので

ExcellaでExcellを分析中に org.apache.poi.hssf.record.RecordFormatException で
Not enought data (1) to read requested (2) bytes .... ってなんやそれと。

事例検索してみたら、オートフィルタやセルの結合、セルに名前を付けるなどが
原因説があったので問題があるセルをさがしてみた。
1000行とかあったので、こういう時は二分木で頑張るのだ、と500,250、125と
絞り込み問題のセルを発見したが、名前が付いてるわけでもなく
結合されているわけでもなく、ただの文字列。こりゃ(´(・)`)クマッタ・・と。

海外の事例にはpoiのバグだろって説もあったので岩にもすがる気持ちで
poiを更新。Excellaに入っていたpoiは最新のrelease版。(3.7-20101029)
こりゃダメか・・・と思ったが、β版が2011/4のビルドだったのでこれに置き換えてみたところ
あっさりとエラー回避。

半日悩んだのはなんだったのか。
同じ憂き目にあわれた方用にメモしておく。
posted by koteitan at 14:21| Comment(2) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2011年04月11日

[java]jarファイルの差し替え

あるクラスだけ埋め込み直したい、元のjarを極力触りたくない。
ってな場合は「u」オプションを使う。


jar uvf hoge.jar jp/co/hoge/fuga.class


uなんかつかったの初めてかもしれんわ、ので備忘録と。

posted by koteitan at 14:02| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2011年02月28日

[java]ExCella Reports Tips(1)

備忘録的に。

ExCella Reports でparseすると以下のエラーの場合、分析するカラムが数式やマクロになっていないか、チェック。

・Cannot get a error value from a numeric formula cell Excella
・Not enough data (1) to read requested (2) bytes Excella


大量に有る場合は、それこそVBAで一括処理とかしないと無理だが
1枚や2枚な場合(初期導入などで)は全選択-コピー-形式を指定して貼り付け-値で
数式を全部消去すればよい。

posted by koteitan at 13:28| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2011年02月23日

[Java]gerResource()

ヽ(τωヽ)ノ モウダメポ

こんなしょうもないミスで1時間ぐら悩んだ。
恥だが、同様の問題をくらった輩のために記録
WEB-INF/classes/aaaa.prop のloadをするには


× new hoge().getClass().getClassLoader().getResourceAsStream("aaaa.prop");
○ new hoge().getClass().getResourceAsStream("aaaa.prop");

昔同じようなのでドツボにはまって調べて、作ったソースがあるし
マイソースDIRからgrepしたらちゃんと

pr.load(a.getClass().getResourceAsStream("hoge.cfg"));

とか発見してるのに、気付いてないんだぜ・・・。
注意力散漫だなぁ。ハァ。
自信満々で飛車を成りこみ、且つ王手金取り!
はっはっは、この雑魚めwww 

バシュウン! と遙か後方の馬に龍を抜かれ、(; ゚Д゚)! となるわけだよ。(即投了)
まったく。
注意力を高めるにも将棋はいいぞ。昨日夢にまででてきたからな・・その局面。

posted by koteitan at 15:41| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2011年01月27日

[java]javaCC

1000行も2000行もあるメソッドの分析なんて手動でやってられねぇええ!!
ていうか、こんなのメソッドじゃねぇ!
一回だけかと思ったら何回も何回も。いったいいくつあるんだ、これ。

というわけで字句解析だけでも機械化したい。
grepして数えてエクセルに田植えとか人間様がやる作業じゃない。

字句解析→コンパイラ→javaCC→時間短縮→HR上げに行ける→ヽ(゚∀゚)ノ

ということで、無い資料と格闘しながらがんばってみた。
superの解釈とかちょっと曖昧だけど、
メソッド中に
 ・呼ばれたメソッドの種類
 ・回数
 ・ifの最大深度
をソースファイルを喰わせれば出力できるように。
静的解析ツールとかにありそうな気がするがまぁ、いいわ。

追記は調べるのにつかった資料やHP、blogなど
感謝感謝でござります。

しかし、if最大深度:10とか出たときは自分のロジックを疑ったぜ・・。
ソースみたら、そこ空白行だしよ。右スクロール(全画面表示)したらでてきたけど。

YYYYYYYYYYからN----------までだからええと
YYYYYYYYYY
YYYYYYYYYN
YYYYYYYYN-
YYYYYYYN--
1+10の11と通り。
途中でelse分岐があるからその分*2で、ええと・・・
elseをgrepすると、8とかでるから、ええと、ええと・・・
N段目のelseだとΣN*2になるんかな。
(N段目までの分岐ケース合計がそこで倍加)

ほんまにテストしたんか!
アァ?( ´Д`)σ)Д`)ァゥァゥ 


続きを読む
posted by koteitan at 14:46| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする