タグ

関連タグで絞り込む (146)

タグの絞り込みを解除

Javaに関するkei_yam1209のブックマーク (110)

  • Java で引数の null チェックで迷った話 - yukungのブログ

    これは Java Advent Calendar 2015 の 15 日目の記事です。 昨日は @opengl_8080 さんの Byteman 使い方メモ+α でした。明日は @irof さんです。 前置き ついこないだチームでちょっとだけ話題に上って、みんなある程度指針は持っているものの、割と悩みつつ明確に答えを出せなかったので、もっと良い意見があればと思って晒してみます。まぁよくある話だし、Java 8 で Optional が使えるようになって null について語られるケースが増えたと思うので、再考するちょうどよい機会になればいいなーと思います。初心者向けです。 どう処す?処す? こんな状況の時にあなたならどうしますか? // Generics なのは例です。String でもなんでもいいです public T doSomething(T input) { // input が

    Java で引数の null チェックで迷った話 - yukungのブログ
  • ちょっといいJavaコードを書こう - Qiita

    一人でプログラムを書いてたりすると、環境によってはあまりコードの書き方には指摘を受けなくて困りますよね。プロになっても、曲がりなりにもちゃんと動くコードを書けてしまうとあまりに当たり前のことなんかは指摘されることも稀で、そのままある程度偉くなっちゃった日には、もはや自分で気付くしかなくなってしまいます。 FindBugsとか、Effective Javaなら使ったり読んでみたり読ませたりすることはできますが、それ以前のところって難しいんですよね。よいコードと言うよりそれが当たり前だと思われているので、指摘するにしても「こうすればいいよ」(アドバイス)じゃなくて「なんでこうしてないの?」(詰問)になってしまいがちです。 そこで、最近そういうJavaニュービーに指摘している(したい)ことの多い、Javaの基礎的な事柄をまとめてみました。ワタシJavaチョットデキルって人は、これ以外にもやりがち

    ちょっといいJavaコードを書こう - Qiita
  • Reactive Streams 入門 #jjug

    2015/06/24 JJUG ナイトセミナー 「Reactive Streams特集」 by @okapies https://jjug.doorkeeper.jp/events/26547 補足記事: http://okapies.hateblo.jp/entry/2015/06/26/024505

    Reactive Streams 入門 #jjug
  • java-mysql-diff が出た - その手の平は尻もつかめるさ

    java-mysql-diff が出ました.Maven Central にもリリースしています. http://search.maven.org/#artifactdetails|net.moznion|mysql-diff|1.0.0| パッケージは id:onishi さん作の mysqldiff の Java 8 移植版です. 最近 Java の環境で作業することが多いので,なんだかんだで Java 版があると便利だよね〜ということで作成しました. 家の Perlmysqldiff と同じような感覚で利用したかったので,全部の依存パッケージを1つにまとめた fat-jar も用意してあります. java -jar というコマンドを余分にタイプする必要はありますが,Perl 版と同じような感覚で利用することが出来ます. https://github.com/moznion/j

    java-mysql-diff が出た - その手の平は尻もつかめるさ
  • JavaでRDBデッドロック検出 - Qiita

    http://cs.hatenablog.jp/entry/2013/07/09/234554 RDB操作でデッドロックは不可避です。ご確認ください。 DBでのデッドロックの発生は、直ちにシステムが停止することを意味しません。DBMSはデッドロック発生を検出してトランザクションを失敗させる機能を持っているからです。 アプリケーションの開発者がすべきことはただ一点、 デッドロック検出時のリトライ です。更新処理だけじゃないです。参照処理でも忘れちゃいけません。約束です。 Javaの場合デッドロック発生はコード的にどう検知すればいいかというと、SQLExceptionが内部にSQLSTATEというRDB共通のエラー番号を持っているのでこれで判別可能となっています。 SQLSTATEの一覧は日立さんのこのまとめが役に立ちます。拝承。 http://www.hitachi.co.jp/Prod/c

    JavaでRDBデッドロック検出 - Qiita
  • null使ったら負け福岡版

    ピュアJavaだと思った?残念androidでした~いつからAndroidJavaだと錯覚していた?~JustSystems Corporation

    null使ったら負け福岡版
  • Java並行処理プログラミング 第16章ver2

    Apache Config preforkについて 8 <ifmodule> 9 StartServers 8 10 MinSpareServers 5 11 MaxSpareServers 20 12 ServerLimit 256 13 MaxClients 256 14 MaxRequestsPerChild 4000 15 </ifmodule>

    Java並行処理プログラミング 第16章ver2
  • 第八回 #渋谷Java 最近のjava PaaS事情

    第六回 #渋谷java での発表内容です。 http://connpass.com/event/6138/

    第八回 #渋谷Java 最近のjava PaaS事情
  • そんなリザルトキャッシュで大丈夫か? #jjug

    JJUGナイトセミナー2014年9月のセッション 「そんなリザルトキャッシュで大丈夫か?」 のスライドです。

    そんなリザルトキャッシュで大丈夫か? #jjug
  • 導入経緯から理解するストリームAPIとラムダ式 : Java好き

    JavaSE8は、なんといってもストリームAPIとラムダ式。 いろいろとできることが増えたので どこから手をつければよいのか困ってしまうが、 導入経緯を探っていくと理解しやすい。 ここでは、ストリームAPIやラムダ式の周辺が どんな理由で必要になったかを考える。 並列処理にはそれが必要だった 導入経緯をまとめると、次のような話。 (個人の主観的なまとめです。詳細はご自身でお確かめ下さい。) CPUがマルチコア化しているのに プログラム側が対応しきれていないのはもったいない。 並行処理用のAPI(Concurrency Utilities)があるじゃないか。 粒度の大きな処理は問題ないが、 粒度の小さな処理を並列化する場合には使いにくい。 じゃあ、イテレータに注目しよう。 反復されている処理が、簡単に並列化できればうれしい。 イテレータを改良すればなんとかなるのでは。 でも、今の外部イテレー

    導入経緯から理解するストリームAPIとラムダ式 : Java好き
  • MySQL Connector/J (JDBC ドライバ)の罠まとめ - ~saiya/hatenablog

    MySQL JDBC ドライバ(MySQL Connector/J)、JavaMySQL といえばまずコレだが、これまた地味に罠が多い(そして多くの人が踏んで苦しむ)のでまとめてみた。 (2015/03/19) こちら のコメント欄でご指摘ただいた wait_timeout の件について記事修正いたしました。 Summary 以下、いずれもプログラム設計時に理解しておかないと、開発中は大丈夫そうでも実用した途端に苦しまされれてしかも設計から治す羽目になる要注意な罠である: SELECT 結果は全部メモリに載ってしまう (デフォルト設定で) 大量 SELECT する場合は FetchSize, ResultSetType を要設定 利用時には制約があるので、設計段階から考慮しなければならない (後述) idle 時間の「合計で」コネクションが切られる 前回のクエリ処理から一定時間以上経

    MySQL Connector/J (JDBC ドライバ)の罠まとめ - ~saiya/hatenablog
  • 僕にそのコピペを直せというのか(2021年4月版) - Qiita

    ソースコードをコピーアンドペーストで作成したコードクローンの方が信頼性がいいという言説もないことはないですが、多くの場合、コードクローンの存在は我々を土壇場で苦しめることが多いです。 担当者が逃げた、ソースコードを、夜遅くまで修正してリリースしたあとに、実は「コピペで作っているから別の所も全部なおしてテストしてね」とか言われて、作業をやり直すのは、とてもとても悲しいものです。 殆ど同じソースコードを間違い探しのように微妙に変更して、修正していくのは屈辱の極みです。 土壇場において、このような罰ゲームを避けるために、コピペの頻度というものは常時監視しておき、異常な頻度の場合はただちに是正すべきです。 ここでは、コピペの検出を行うツールについて説明します。 PMD-CPD PMDはJavaで実装されたJavaのソースコードの潜在的問題を検出するツールです。 http://pmd.sourcef

    僕にそのコピペを直せというのか(2021年4月版) - Qiita
  • Java の語彙で Maybe を説明してみる - ぐるぐる~

    java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます!そう、直和型なんです!とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe? null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの?」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;

    Java の語彙で Maybe を説明してみる - ぐるぐる~
  • Java、Springのアノテーションめも - ぺーぺーSEのブログ

    SpringアノテーションをJavaと並べてまとめ クラス対象のアノテーション Springアノテーション @Component SpringDIコンテナにbeanとして登録したいクラスへ付与する bean定義ファイル(.xml)のタグと同じ働き bean名をつけたいときは下記のようにする @Component("name") このアノテーションを使うとこはbean定義ファイルに「」を記述しておくこと @Service @Componentと基的には同じ働きをするが、Service層(ビジネスロジック等)を対象としている Service層とその他のbeanの違いを明確にするために使用する このアノテーションを使うとこはbean定義ファイルに「」を記述しておくこと @Repository @Componentと基的には同じ働きをするが、Persistence層(DAO等のDBアクセスを行

    Java、Springのアノテーションめも - ぺーぺーSEのブログ
  • チューニングに使えるJava性能監視ツール

    ヒープ領域とパーマネント領域 JavaVMには、独自のメモリー管理機構が搭載されています。不要になったオブジェクトを定期的に破棄してメモリーを開放するガベージ・コレクション機能と、永続的に使われるオブジェクトであるかどうかを判定する機能が搭載されています。 JavaVMが確保するメモリーには、大きく3つあります。オブジェクトを管理するヒープ領域と、読み込むクラス情報を確保するパーマネント領域、それ以外に、ランタイムが必要とするシステム領域です。 ヒープ領域は、必要に応じて保存と破棄が繰り返される領域となります。クラス情報は、パーマネント領域に格納されます。それ以外に確保されるメモリーとして、ランタイムが利用するシステム・メモリー(OS依存ヒープ・メモリー)とスレッド管理のメモリーが別領域になります。 New領域: ヒープ領域 New領域は、Eden、Survivor0、Survivor1(

  • syboos.jp

  • JAVAヒープサイズ・GCチューニングのまとめ

    システム開発に役立ちそうな情報を日々メモしています。世の中の開発現場が少しでも平和になることを祈ります。 ■ 前提条件 ----------------------------------------------- JVMは、Sun Java (JDK 1.5-1.6)を想定。 ■ 目標 ----------------------------------------------- ・マイナーGC、フル GCがそれぞれ頻発しないこと。 ・フル GCの実行時間が1秒未満であること。 ・マイナーGCの実行時間が0.1秒未満であること。 ・連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 ・理想的な状態は、上記に加えて、フル GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジ

  • 無限ルーパー - javaのヒープメモリの使用状況を確認する

    先日、Tomcatのメモリリークに遭遇した。 直接の原因は、Tomcatのセッションが開放されないことで、ヒープメモリ不足が発生していたことだった。 この問題、ggったら結構よくある問題ようで。 そんなわけで、ヒープメモリやGCについて 詳しく調べることになったのでまとめておく。 javaを語る上で外せないヒープメモリについては、 素晴らしい説明資料が数多くあるため、参考になったサイトを以下に挙げておく。 「Javaのヒープ・メモリ管理の仕組み」 http://www.atmarkit.co.jp/fjava/rensai3/devedge03/devedge03_1.htmlJavaVMのメモリ管理に関するまとめ(Javaヒープ、GC、ダンプ等)」 http://d.hatena.ne.jp/tanakakns/20120508/1336467306 「ガベージコレクタの仕組みを理解

  • wall-climb » コンカレントGCの注意点

    次? 代のサーバマシンによるシステムでは、CPUマルチコア化が進み、OSぜ 64bit化によってメモリも豊富に眩 むような大規模なものが一般的になるのではないでしょうか。このようなサーバ上ぜ Tomcatを起動させる場合、その? 富なリソースを生かしぜ Javaのヒープサイズ、GCチューニングを実施するのが一般的だと思゜ れます。ただし、このオプションを中途半端に? ? すると、逆にパフォーマンスを損なう可能性があることに注? しなければならないようです。 CPUマルチコアリソースを十分に活用する為ぜ GCチューニングパラメータに、「-XX:+UseParNewGC」「-XX:+UseConcMarkSweepGC」があります。前者ぜ GC処理をマルチCPUでパラレルに? 施するオプション、「-XX:ParallelGCThreads=n」と合゜ せてパラレル処理? (n)を指定出来ます。

  • HotSpot JVMの最適化オプションについて調べる - terazzoの日記

    Javaの最適化の議論で「インライン展開」「エスケープアナリシス」などの用語が出てきていて、気になって調べたところ、java実行時のオプションで最適化の方法を指定したり実行過程を表示したり出来るらしい。 主なオプションについて Java HotSpot VM Optionsにパフォーマンスに影響しそうなHotSpot VMのオプションが説明されている。 例: オプション 効果 -XX:+PrintCompilation メソッドがコンパイルされた際にメッセージを表示 -XX:+UseBiasedLocking Biased Lockingを使用する -XX:+OptimizeStringConcat 可能なら文字列の連結操作の最適化を行う -XX:+AggressiveOpts 将来のリリースでデフォルトになりそうな最適化フラグを有効にする ... ... たとえばjava起動時に-XX:

    HotSpot JVMの最適化オプションについて調べる - terazzoの日記