Go実務 問題集・練習問題クイズ

append後も元Sliceが必ず同じBacking Arrayを指すと仮定したコードが壊れました。適切な理解はどれですか？

答え： 容量不足ならappendは新しいBacking Arrayを割り当て得る

SliceはPointer、Length、Capacityを持つViewです。appendの戻り値には再割当て後のSliceが入るため、必ず受け取ります。

mapから値を取得するとき、Key不存在とZero Valueを区別したい。適切なのはどれですか？

答え： value, ok := m[key]を使う

Comma-ok IdiomのokがKeyの存在を示します。不存在でもValueには要素型のZero Valueが返るため、Valueだけでは区別できません。

外部Packageの型に自作Interfaceを実装させたい。Goで必要なことはどれですか？

答え： 必要なMethod Setを持てば暗黙に満たす

GoのInterface実装は暗黙的です。利用側が必要最小限のInterfaceを定義すると、外部型でもMethod Setが一致すれば利用できます。

Structの状態を書き換えるMethodを定義したい。Receiverとして適切なのはどれですか？

答え： Pointer Receiver

Pointer Receiverは元の値を更新でき、大きなStructのCopyも避けられます。同じ型のMethod群ではReceiver種別を一貫させます。

下位Errorに操作情報を加えつつ、呼出側がSentinel Errorを判定できるようにしたい。適切なのはどれですか？

答え： fmt.Errorf("load user: %w", err)でWrapしerrors.Isを使う

%wでError Chainを保持すると、文脈を追加しながらerrors.Isやerrors.Asで原因を判定できます。

FileをOpenした後、途中Returnが複数ある処理でClose漏れを防ぎたい。適切なのはどれですか？

答え： Open成功直後にdefer file.Close()を登録する

Resource取得成功後すぐdeferを登録すると、以降のReturn経路でCloseが実行されます。Close Errorの扱いが重要ならNamed Return等で明示します。

Libraryの入力Validation失敗をpanicで返している。実務APIとして望ましい改善はどれですか？

答え： 通常予想される失敗はerrorとして返す

panicはInvariant破壊など継続不能な事象向けです。入力不備や外部I/O失敗はCallerが判断できるerrorとして返します。

外部API呼出しをRequest中断やDeadlineに連動させたい。適切な設計はどれですか？

答え： Callerのcontext.Contextを第一引数で渡し、Requestへ関連付ける

Contextは呼出Chainで伝播させ、HTTP RequestやDB Queryへ渡します。CancelFuncを作った側はdefer cancel()でResourceを解放します。

PipelineのConsumerが途中終了するとProducer GoroutineがChannel送信で永久Blockする。改善はどれですか？

答え： ContextのDoneと送信をselectし、全StageへCancelを伝播する

各StageがCancelを監視し、送受信のBlockから抜けられるようにするとGoroutine Leakを防げます。

複数WorkerへJobを送るChannelをCloseする責任は通常どこに置きますか？

答え： 送信完了を把握するSender側Owner

本来は送信完了を把握するSender OwnerがCloseします。ReceiverがCloseすると並行Senderのsend on closed channelを招きます。

Unbuffered Channelの送信が完了する条件はどれですか？

答え： 対応するReceiverが値を受け取れる状態になったとき

Unbuffered Channelは送信と受信のRendezvousを作り、双方が準備できるまでBlockします。通信と同期を兼ねます。

selectにdefaultを入れた結果、LoopがCPUを使い切りました。原因と改善はどれですか？

答え： defaultが待機せず実行されるため、BlockingかTimerを設計する

ReadyなCaseがないとdefaultが即時実行され、Busy Loopになります。待つべき処理ではdefaultを外すかTimer等を使います。

大量Jobを並列処理したいが、入力数だけGoroutineを作ってMemoryを圧迫したくない。適切なのはどれですか？

答え： 固定数WorkerがJob Channelを読むBounded Worker Pool

Worker数で同時実行数を制限し、QueueとBackpressureを設計します。Contextで停止し、Error回収と終了待ちも行います。

複数Goroutineが同じmapを読み書きする。適切な保護はどれですか？

答え： Ownershipを1 Goroutineへ集約するかMutex等で同期する

通常mapの並行Read/Writeは安全ではありません。所有権移譲、Mutex、用途に合うsync.Map等を選びます。

CIで共有変数のData Raceを検出したい。使うべきCommandはどれですか？

答え： go test -race ./...

Race Detectorは実行されたMemory AccessをInstrumentationで監視します。並行経路を通るTestやIntegration Testで実行します。

複数Goroutineの完了を待ってから結果ChannelをCloseしたい。適切なのはどれですか？

答え： sync.WaitGroupで完了を数え、Wait後にCloseする

Addは開始前、各Workerはdefer Done、CoordinatorがWait後に一度だけCloseします。二重Closeと送信中Closeを防げます。

高価なClient初期化を複数Goroutineから呼んでも一度だけ実行したい。適切なのはどれですか？

答え： sync.Once

sync.Once.DoはConcurrent Call下でも関数を一度だけ実行し、完了のMemory Visibilityも同期します。

複数Fieldを一貫した状態で更新する必要がある。atomic Counterだけで十分ですか？

答え： 複合InvariantにはMutexまたはImmutable Snapshot公開を使う

Atomic Operationは単一値の更新には有効ですが、複数値間のInvariantを自動では守りません。Critical SectionかSnapshot単位で同期します。

外部HTTP API Clientが応答しないとGoroutineが溜まる。基本改善はどれですか？

答え： 再利用するhttp.ClientへTimeout/Transport Timeoutを設定し、Contextも伝播する

Client/Transportは再利用し、接続・Header・全体Deadlineを要件に合わせます。Response Bodyは必ずCloseし、Retryは回数とBackoffを制限します。

Inbound HTTP Requestが切断されたら下流DB Queryも中断したい。適切なのはどれですか？

答え： r.Context()をQueryContextへ渡す

http.RequestのContextはClient切断やServer処理終了でCancelされます。対応APIへ渡すと不要な下流処理を止められます。

Public HTTP ServerをSlowloris等から守る基本設定はどれですか？

答え： http.ServerのReadHeaderTimeout等を要件に合わせて設定する

ReadHeaderTimeout、ReadTimeout、WriteTimeout、IdleTimeoutをTraffic特性に合わせ、Reverse ProxyのTimeoutとも整合させます。

Kubernetes終了Signal時にGo HTTP Serverを安全に停止したい。適切なのはどれですか？

答え： Signal Contextを受け、期限付きContextでServer.Shutdownを呼ぶ

新規受付を止め、処理中Requestへ猶予を与え、Deadline超過時は強制終了方針へ移ります。Readinessも先に落とします。

JSON APIでStruct Field名とWire名を分離し、空値を省略したい。適切なのはどれですか？

答え： Exported Fieldへjson:"user_id,omitempty" Tagを付ける

encoding/jsonはExported Fieldを扱い、Struct TagでWire Nameやomitemptyを指定します。omitemptyのZero判定は型ごとに理解します。

設定JSONのTypoを静かに無視せず、未知FieldとしてErrorにしたい。適切なのはどれですか？

答え： json.Decoder.DisallowUnknownFieldsを有効にする

厳格な設定読込ではDecoderのDisallowUnknownFieldsを使い、必須値やRangeはDecode後に別途Validationします。

database/sqlでUser入力を含むQueryを安全に実行したい。適切なのはどれですか？

答え： Placeholderと引数Bindingを使う

Driverに合うPlaceholderで値をBindingし、識別子の動的切替はAllowlistで設計します。文字列連結はSQL Injectionを招きます。

複数SQL更新をTransactionで実行し、途中Errorなら確実にRollbackしたい。定石はどれですか？

答え： BeginTx後にdefer Rollbackを登録し、成功時だけCommitする

defer tx.Rollback()はCommit済みなら無害なErrorとなり、途中ReturnをCoverします。Transaction中はtxのMethodを使います。

数GBのUploadをMemoryへ全読込せず処理したい。適切な抽象はどれですか？

答え： io.ReaderからStreamingし、必要ならio.Copyを使う

io.Reader/WriterはChunk単位のStreamingを可能にします。Size Limit、Context Cancel、Partial Write Errorも扱います。

bufio.Scannerで非常に長い1行を読むとScanが停止した。適切な対応はどれですか？

答え： 要件に応じScanner.Buffer上限を設定するかbufio.Readerを使い、Errを確認する

ScannerにはToken Size上限があります。信頼境界では無制限化せず妥当な上限を定め、Scan終了後のErrを処理します。

同じ関数へ多数の入力と期待値を適用するTestを読みやすくしたい。適切なのはどれですか？

答え： Table-driven Testとt.RunでCase名を付ける

入力・期待値・名前をTableにし、Subtest化すると追加と失敗特定が容易です。並列化する場合は共有状態に注意します。

HTTP Handlerを実PortなしでUnit Testしたい。適切なのはどれですか？

答え： httptest.NewRequestとhttptest.NewRecorderを使う

httptestのRequest/RecorderでHandlerを直接呼び、Status、Header、Bodyを検証できます。Client統合にはhttptest.Serverも使えます。

Optimization前後の処理時間とAllocationを比較したい。適切なのはどれですか？

答え： testing.BのBenchmarkと-benchmemを使う

Go Benchmarkは反復回数を調整し、ns/opやallocs/opを測れます。安定環境で複数回測りbenchstat等で比較します。

Parserへ予想外の入力を与えてCrashやInvariant破壊を探したい。適切なのはどれですか？

答え： Go Fuzz TestへSeed CorpusとInvariantを定義する

FuzzingはSeedから入力を変異させ、panicやTest Failureを最小化して保存します。Security境界のParserに有効です。

Import変更後にgo.mod/go.sumの不要・不足Dependencyを整理したい。適切なCommandはどれですか？

答え： go mod tidy

go mod tidyは必要なModule RequirementとChecksumを追加し、不要なものを削除します。CIでは実行後Diffがないことを確認できます。

go.sumの主な役割はどれですか？

答え： DownloadしたModule ContentのChecksumを記録し検証に使う

go.sumはModule Versionとgo.mod ContentのHashを記録し、同じVersionの改ざんや不一致検出に使われます。通常RepositoryへCommitします。

Repository内だけで使うPackageを外部ModuleからImport不能にしたい。適切なのはどれですか？

答え： internal Directory配下へ置く

Go Toolchainはinternal DirectoryのImport範囲を強制します。APIを不用意に公開せずRefactor余地を保てます。

複数ModuleをLocalで同時開発するためgo.workを使う。CIで注意すべきことはどれですか？

答え： CIが意図せずLocal Workspace組合せをTestしないようGOWORKと各Module単体を確認する

go.workは便利ですが、CIで依存ModuleのReleased VersionではなくLocal Moduleを選ぶ可能性があります。各Moduleの単体成立を検証します。

利用中Dependencyの既知脆弱性が実際のCall Pathへ到達するかGo向けに確認したい。適切なのはどれですか？

答え： govulncheck ./...

govulncheckはGo Vulnerability DatabaseとCall Graph分析を使い、利用Codeに影響する既知脆弱性を低Noiseで報告します。

本番相当負荷でCPU HotspotとAllocation元を調査したい。適切なのはどれですか？

答え： runtime/pprofまたはnet/http/pprofでProfileを採取しgo tool pprofで分析する

CPU、Heap、Goroutine等のProfileを対象期間で採取し、Flame GraphやTopでCost Centerを特定します。Endpointは認証・Network制限します。

分散環境のLogを検索しやすくし、Requestを追跡したい。Go ServiceのLog設計として適切なのはどれですか？

答え： slog等でLevel・Message・Request ID・Operation・Errorを構造化Fieldとして出す

Structured LoggingはField単位のFilterと集計を容易にします。Trace/Request IDをContextから渡し、Credentialや個人情報をRedactします。

Container化したGo Serviceを小さく安全に配布し、Signalで正常終了させたい。適切な組合せはどれですか？

答え： Multi-stage BuildでBinaryを作り、最小Runtime Imageとsignal.NotifyContextで終了処理する

Build ToolchainをRuntimeから分離し、必要なCA証明書・Timezone等だけを含めます。Signal Contextから期限付きGraceful Shutdownを実行します。